Agentic yapay zeka konuşmalarında son dönemin en popüler tavsiyesi şu: “Ajana hedefi ver, gerisini ona bırak.” Otonom planlama yapsın, araçlarını seçsin, kendi başına çözsün. Kulağa çekici geliyor farkındayım ama son birkaç aydır üzerinde çalıştığım bir proje bana tam tersini öğretti. Bence LLM’lerle dans etmenin en önemli kuralı mikroyönetimdir.

Ama burada kastettiğim, satır satır ne yazacağını söylemek değil. “Şunu yap, şimdi bunu yap, sonra şunu yap” tarzında modele adım dikte etmek de değil. Kastettiğim şu: modelin yetkilerini tanımlamak, sınırlarını çizmek, karar alanını daraltmak, ne zaman duracağını belirlemek ve hangi konularda insandan onay alacağını netleştirmek. Kısacası, prompt’u değil sistemi mikroyönetmek.

Bu ayrımın neden kritik olduğunu, sektörde neye karşılık geldiğini ve neden “daha zeki model” yerine “daha iyi tasarlanmış harness” argümanının çok daha güçlü olduğunu anlatmaya çalışacağım.

İki Çeşit Agentic Mikroyönetim Var

İnsanları mikroyönetmek verimi düşürür. Bunu herkes bilir. İnsan bağlam kurabilir, sorumluluk alabilir, eksikleri hissedebilir ve organizasyonun hedefini sezgisel olarak anlayabilir. Bu yüzden ona “git hallet” demeniz çoğu zaman yeterlidir; hatta daha iyidir.

LLM’lerle çalışırken ise durum farklıdır. LLM amacı hissetmez, kurumsal bağlamı bilmez, risk algısı yoktur. “Emin değilim” demek yerine çoğu zaman boşluğu doldurur. Özgüveni hata oranından yüksektir. LLM özgürlük istemez. LLM sınır ister. Çünkü özgür kaldığında eksik bilgiyi tamamlamaz, uydurur.

“Git hallet” dediğiniz anda kapsam genişler, varsayımlar çoğalır, olmayan gereksinimler ortaya çıkar ve mimari kararlar sessizce alınır. “Restoran uygulaması yap” dersiniz; iki dakika sonra multi-tenant SaaS, Stripe entegrasyonu, Kubernetes, event sourcing, Redis, admin paneli ve analytics eklemiş bulursunuz. Çalışan ama yanlış bir şey elde edersiniz.

Burada iki farklı mikroyönetim düzeyini ayırmak gerekiyor:

Prompt seviyesinde mikroyönetim — yani modele adım adım ne yapacağını dikte etmek, kötüdür:

Şimdi bunu yap.
Şimdi şunu yap.
Şimdi onu yap.

Bu ölçeklenmez, her ajanın başında bir iş gücü görevlendirmek gerekir. Modelin planlama ve akıl yürütme kapasitesini boğar. Bazı kaynaklarda “agentic mikroyönetim” olarak adlandırılıp eleştirilen şey de aslında budur.

Mimari seviyede mikroyönetim — yani modelin çalışma ortamını, yetkilerini ve karar sınırlarını tasarlamak ise oldukça gereklidir:

Bu aracı kullanabilirsin.
Şunu kullanamazsın.
Bu durumda dur.
Bu durumda insandan onay al.
Bu durumda yeniden dene.
Ready kararını sen veremezsin.

Bu ikisini kimse birbirinden yeterince ayırmıyor. Ama ayrım kritik. Birincisi modelin akıl yürütme kapasitesine müdahale ediyor. İkincisi ise modelin çalışma ortamının mühendislik tasarımını ifade ediyor.

Modeli Değil, Harness’ı Konuşmak

Peki mimari seviyede mikroyönetimin teknik karşılığı ne?

Sektörde buna genellikle harness deniyor. Bu terim elektrik ve otomotiv tarafındaki kablolarla kurulan kontrol tesisatlarından geliyor. Türkiye ekosisteminde hali hazırda bunu kablolama, kablaj, düzenek olarak da çeviren kaynaklar mevcut. LangChain bunu “agent harness” olarak açıkça adlandırıyor ve benzer bir metaforla, modelin kendisi dışında kalan bağlamı, araç kullanımını, hafızayı, durum yönetimini ve hata döngülerini kontrol eden yazılım ekosisteminin tamamı olarak tanımlıyor. Yani model tek başına bir ajan değil, onu asıl faydalı kılan şey etrafındaki altyapı.

Anthropic’in “Building Effective Agents” dokümanı, bu yaklaşımı belki de en net ortaya koyan kaynak. Anthropic iki mimari arasında kesin bir ayrım yapıyor: iş akışı (önceden tanımlı kod yollarında LLM’in orkestre edildiği yapılar) ve ajan (modelin süreci ve araç kullanımını dinamik olarak yönettiği yapılar). Ve açık bir tavır koyuyor: “Önce en basit çözümle başlayın. Karmaşıklığı ancak çıktıyı ölçülebilir biçimde iyileştiriyorsa artırın.” Kablo ne kadar uzarsa o kadar ayağımıza dolanacaktır.

Yani en büyük agentic AI sağlayıcılarından biri bile diyor ki: esneklik ve otonomi ancak gerçekten gerektiğinde katlanılan bir maliyettir, bir hedef veya marifet değildir.

OpenAI tarafında aynı fikir farklı bir dille ürünleşiyor. Agents SDK, karmaşık agentic akışları birkaç temel ilkeye böler: ajanlar, görev devri, koruma bariyerleri, oturumlar, izleme/kayıtlama ve insan onayı. Yani ajan tek bir sihirli nesne değil, kontrol noktalarıyla kurulmuş bir bileşimdir. OpenAI’nin kendi ifadesiyle: döngüyü, araç yürütmeyi, koruma bariyerlerini ve oturum yönetimini çalışma zamanı katmanına bırakmak başka; bunları doğrudan sahiplenmek başka bir tasarım tercihidir.

Google ADK tarafında da benzer bir yaklaşım var. Burada deterministik kod akışları ile adaptif akıl yürütme katmanını birlikte düşünmek önemseniyor. Graph tabanlı yapılar, açık yürütme yolları ve daha öngörülebilir çıktılar için kullanılıyor.

LangGraph ise konuyu doğrudan orkestrasyon problemi olarak ele alıyor. Örneğin kesme ve duraklatma modeli tek cümlede şöyle özetlenebilir: kritik eylemden önce dur, insan onayı al, gerekirse sistemin durumunu düzenle, sonra devam et. Kalıcı yürütme (durable execution) ile bir sunucu çökse bile sistemin en son kontrol noktasından tam bağlamla devam edebilmesini garanti ediyor.

Bütün bu kaynaklar farklı diller kullanıyor ama söyledikleri şey aynı: modeli özgür bırakmak yerine, ona daraltılmış karar alanları, belirlenmiş araç izinleri, kontrol noktaları, insan onayları, gözlemlenebilir durum ve sınırlandırılmış çalışma zamanı katmanı ver.

Güvenlik Bunu Zorunlu Kılıyor

Bu sadece kalite meselesi değil, doğrudan güvenlik meselesi. OWASP, “Excessive Agency” yani haddinden fazla yetkilendirilmiş ajan davranışı kavramını artık LLM uygulamalarındaki en kritik risk başlıklarından biri olarak tanımlıyor. Tanımı net: bir LLM sistemine gereğinden fazla araç erişimi, gereğinden geniş veritabanı hakları ve kritik işlemleri insan onayı olmadan kendi başına yapabilme gücü verilmesi. Sorun yalnızca modelin hata yapması değil, fazla yetkili bir modelin yanlış şeyi gerçekten yapabilmesi.

NIST AI Risk Management Framework de aynı yönde: insan-AI rol ayrımı, gözetim süreçleri, üçüncü taraf riskleri ve devreden çıkarma mekanizmalarını doğrudan yönetişim meselesi olarak çerçeveliyor.

MCP (Model Context Protocol) spesifikasyonu bile kullanıcı onayı, yetkilendirme, araç güvenliği ve token hedef kitle doğrulamasını şart koşarak ajanın yalnızca “bağlanan” değil, “yetkiyle bağlanan” bir şey olduğunu netleştiriyor. Bu kaynakların hepsi farklı perspektiflerden aynı sonuca varıyor: kontrolsüz ajans sadece kalitesiz çıktı değil, doğrudan güvenlik açığıdır.

“Daha İyi Model” Yanılgısı

Çoğu ekibin çözüm düşüncesi, çıktı kalitesi düşükse daha güçlü model kullanmaya odaklanıyor. Oysa pratikte gördüğüm tablo farklı. Mesele modelin zekası değil, o zekanın çalıştığı ortamın kalitesi.

Akademik çalışmalar bu fikri birebir “mikroyönetim” diye adlandırmıyor ama ajan-bilgisayar arayüzü, iskele (scaffolding) ve yansıtma döngüsü gibi kavramlarla aynı yöne işaret ediyor.

SWE-agent araştırması bunun en net örneğini ortaya koyuyor. Araştırmaya göre başarı, modelin kabiliyetinden çok ona sunulan çalışma yüzeyinin tasarımıyla doğrudan değişiyor. Aynı model, farklı harness mimarileriyle sarıldığında çok farklı performanslar veriyor. Araçlar katı sınırlandırılmış çıktılar üretmeli, kod düzenlemeleri anında bir kod denetleyiciden geçmeli, hatalıysa otomatik olarak geri alınarak hata modele rapor edilmeli ve “Evet, kesinlikle çok haklısın.” sululuğuyla birlikte model cevabı düzeltmeli. Kağıt üstünde kulağa zor geliyor ama sahada fark tam olarak modelin duygusuz ve katı kurallı bir müdüre rapor vermesiyle ortaya çıkıyor.

Reflexion çerçevesi de aynı doğrultuda: hata sonrası dilsel geri bildirim ve deneyimsel hafıza mekanizmasıyla, mikroyönetimin sadece kısıt değil geri besleme yapısı olduğunu gösteriyor.

ReAct yaklaşımı da bu düşüncenin erken örneklerinden biri. Model önce düşünür, sonra bir eylem yapar, sonucu gözlemler ve buna göre yeniden düşünür. Yani tek seferde cevap üretmek yerine, düşünme ve aksiyon alma arasında gidip gelen bir döngü kurar. Ama bu döngüyü güvenilir yapan şey yalnızca modelin zekâsı değildir. Asıl farkı yaratan, bu düşünme-eylem döngüsünün etrafına kurulan kontrol katmanıdır.

Pratikte çoğu zaman şu formül geçerli:

Orta model + iyi harness + iyi bağlam + iyi durum yönetimi + iyi sınırlar

>

Çok güçlü model + "git hallet"

Prompt Mühendisliği Değil, Yetki Tasarımı

Aslında burada yapılan şey prompt mühendisliği değil. Daha doğru bir tanım: yetki tasarımı. Her noktada şu soruyu sormak gerekiyor: bu kararı kim verecek?

Bazı kararlar modele bırakılabilir. Örneğin bilinen gerçekleri çıkarmak, bilinmeyenleri listelemek, soru önermek, kabul kriteri yazmak gibi alanlarda model serbesttir. Ama işin hazır olup olmadığına karar vermek, neyin engelleyici sorun sayılacağını belirlemek, kapsamı değiştirmek, yıkıcı bir aksiyona onay vermek gibi önemli kararlar modele bırakılmamalıdır. Bunlar harness’ın, uygulamanın veya doğrudan insanın alanıdır.

Bu karar dağılımını doğru kurmak, modeli daha zeki yapmaktan çok daha fazla değer üretiyor. Modelin zekası çoğu iş için zaten yeterli. Asıl sorun o zekanın neyi hatırlayacağını, neyi göz ardı edeceğini ve neye odaklanacağını belirleyen çalışma ortamının kalitesidir. Bunu konuşmadan “hangi modeli kullanalım?” tartışması yapmak biraz kendimizi kandırmaktır.

Bir Adlandırma Meselesi

Bu konuyu araştırırken fark ettiğim şey, anlattığım pratiğin parçalarının sektörde zaten mevcut olduğu ama bütünsel bir ismin henüz tam oturmadığıydı. İş akışı orkestrasyonu, koruma bariyerleri, insan onayı, deterministik orkestrasyon, politika motoru, durum makinesi, en az ayrıcalık, iskele gibi terimlerin hepsi aynı düşüncenin farklı yüzleri.

Piyasada bu kavrama en yakın duran terimler:

• Harness Engineering — modelin etrafındaki mimariyi kurarak kontrol altına almak. En yaygın sektör terimi.
• Bounded/Constrained Autonomy — otonomiyi sınırlandıran çerçevenin çizilmesi. En olgun kavram.
• Deterministic Orchestration — akış kararlarının modele değil kural tabanlı mantığa bırakılması.
• Controlled Agency — en akademik ve savunulabilir tanım.

Ben bu düşünceyi daha keskin bir çerçeveye oturtmak istiyorum. Bence, “LLM’lerle dans etmenin kuralı sistemi mikroyönetmektir.” Yeni bir protokol veya kuram önermiyorum, mevcut en iyi pratiklerin ortak bir çatısını, saha deneyimimden süzülen bir perspektifle sunuyorum.

Ne Yapmalı: Pratik Mimari İlkeler

Buraya kadar okuyan “tamam güzel hikaye, peki uygulamada ne yapacağız?” diyebilir. Kendi deneyimimden ve kaynaklardan çıkardığım temel ilkeler:

• LLM karar verici değil, öneri üretici olsun. Model bilinen gerçekleri çıkarsın, bilinmeyenleri bulsun, soru önersin, kabul kriteri yazsın. Ama hazır olup olmadığına, neyin blocker sayılacağına ve hangi eksikliğin kritik olduğuna uygulama karar versin.
• Durum görünür ve kalıcı olsun. Sistem durumunu geçici bellekte değil kalıcı olarak saklayın. Hata veya insan onayı durumunda en son kontrol noktasından devam edebilmelisiniz. Buna kalıcı yürütme deniyor.
• Araç yetkileri “en az ayrıcalık” ilkesiyle verilsin. Model her araca erişemesin. Hangi aracı, hangi koşulda, hangi izinle çağırabileceğini açıkça tanımlayın.
• Blocker varsa ilerleme olmasın. Kritik bir sorun çözülmeden sistemin bir sonraki aşamaya geçmesi engellensin. Bu karar modelin inisiyatifinde olmamalı.
• Onay mekanizmaları bulunsun. Yıkıcı eylemlerden, scope değişikliklerinden veya geri dönüşü zor aksiyonlardan önce insan onayı zorunlu olsun.
• Çıktı şeması ve doğrulama olsun. Modelin çıktısını serbest metin olarak değil, tanımlı bir şemaya (JSON, yapılandırılmış format) göre alın ve doğrulayın.
• Yeniden deneme ve güvenli başarısızlık aksiyonları deterministik olsun. Hata durumunda modelin ne yapacağı önceden tanımlanmış kurallara bağlı olsun; “kendi başına çözmeye çalış” değil.
• Görev devri ve hazır olma kararları yazılım katmanında olsun. Bir görevin tamamlandığını veya bir sonraki aşamaya geçilmesi gerektiğini modelin kendi başına ilan etmesine izin vermeyin.

Sonuç

Agentic sistemlerde asıl mesele modele daha fazla özgürlük vermek değil; özgürlüğü doğru yerde, doğru dozda ve doğru kontrollerle vermek. Bu işin literatürdeki adı henüz tam yerleşmemiş olabilir. Ama sektör bize yeterince ipucu veriyor: iş akışı orkestrasyonu, koruma bariyerleri, iskele, harness, insan onayı ve sınırlandırılmış otonomi gibi kavramlar.

Bence bu kavramların ortak paydasını en iyi anlatan cümle şu: İnsanları mikroyönetmek verimi düşürür. LLM’leri prompt seviyesinde mikroyönetmek de sistemi boğar. Ama agentic sistemlerde kalite, mimari seviyede mikroyönetimden gelir.

Güçlü modeller hata yapar. İyi tasarlanmış harness’ler hata yapabilecek alanı küçültür. Mesele modeli daha akıllı yapmak değil, yanlış karar verebileceği alanı küçültmek. Bu yüzden soru “bu modele ne yaptırabilirim?” değil; “bu modelin ne yapmasına izin vermemeliyim?” olmalı. Önce teşhis, sonra sistem, en son teknoloji.

Referanslar

Birincil Kaynaklar (Resmi Dokümanlar ve Standartlar):

• Anthropic. “Building Effective Agents.” (Aralık 2024). Workflow-agent ayrımı, basit ve birleşebilir desenlerin önceliği. anthropic.com/research/building-effective-agents
• OpenAI. “Agents SDK Documentation.” Guardrails, handoffs, sessions, tracing ve human-in-the-loop mimarisi. openai.github.io/openai-agents-python
• LangGraph. “Overview and Interrupts Documentation.” LangChain ekosistemi altında yayımlanan LangGraph dokümantasyonu. Agent harness, durable execution, checkpoint tabanlı state yönetimi. docs.langchain.com
• OWASP. “Top 10 for LLM Applications 2025 — LLM06: Excessive Agency.” Kontrolsüz ajansın güvenlik riski olarak tanımlanması. genai.owasp.org
• NIST. “AI Risk Management Framework (AI RMF 1.0).” (Ocak 2023). Yönetişim, insan-AI rol ayrımı, gözetim süreçleri. nist.gov/ai-risk-management-framework
• MCP Specification. Model Context Protocol — kullanıcı onayı, tool safety, OAuth 2.1 yetkilendirme. spec.modelcontextprotocol.io
• Google ADK. “Agent Development Kit Documentation.” Deterministic code + adaptive reasoning, graph workflows. adk.dev

Akademik Kaynaklar:

• Yao, S. et al. “ReAct: Synergizing Reasoning and Acting in Language Models.” (2022). Reasoning-action döngüsünün kurucu çalışması.
• Schick, T. et al. “Toolformer: Language Models Can Teach Themselves to Use Tools.” (2023). Araç kullanımının model tarafından öğrenilmesi.
• Shinn, N. et al. “Reflexion: Language Agents with Verbal Reinforcement Learning.” (2023). Hata sonrası dilsel geri bildirim ve episodik hafıza.
• Yang, J. et al. “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.” (2024). Modele sunulan çalışma yüzeyinin tasarımının performansa etkisi.
• Agaoglu, A. et al. “Inside the Scaffold: Taxonomizing Coding Agent Scaffolds.” (2026). Scaffold mimarilerinin sınıflandırılması.

 Sektörel Ölçeklenebilirlik: Havacılık sektörü baz alınarak kurgulanan bu mimari tasarım; otomotiv, ağır sanayi ve genel endüstriyel makine imalatı bantlarına benzer üretim alanlarına gelecekte uyarlanabilir esnekliktedir.

Proje Künyesi

Mevcut Durum ve Sorun

Bağlam: Savunma sanayiinde otonom platform ürünlerinin (TB2, AKINCI vb.) entegrasyon sahaları, katı regülasyonlar (traceability compliance) gerektirir. Fabrika bandındaki her bir fiziksel donanımın; hangi onaylı sipariş partisinden çekildiği, o istasyondaki kim tarafından kurgulandığı ve en nihayetinde hangi ana gövdeye yüklendiği zorunlu denetim (audit) kayıtlarıdır.

Kritik Sorunlar: Dijital ve rollere bağlanmış eşzamanlı bir kontrol mekanizması bulunmadığında, farklı platformlara ait yapısal parçaların karışma veya uyuşmama riski büyür. Yetki tanımlarının ve stok verilerinin (FIFO prensibinden uzak) ERP dışında yalnızca manuel pusulalarla (worksheet) yönetilmesi geriye dönük kök neden analizi (root-cause) yapabilmeyi olanaksızlaştırır.

Çözüm Mimarisi ve Aksiyon

Mimari Yaklaşım: Tamamen role-based güvenlik kısıtlarına ve asimetrik veri yönetimini sıfırlayan deterministik stok tahsisine dayanan üç katmanlı (3-tier) bir API mimarisi tasarlandı.

Uygulanan Metodoloji

Donanım (UUID) Serialization İşlemi

Her üretilen fiziksel donanım, veritabanına UUID formunda entegre edilir. Bu sayede üretim zamanı, parti türü ve hangi montaj hattına entegre edildiği asgari hata ile kayıt altına alınır:

class Part(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    part_type = models.ForeignKey(PartType, on_delete=models.PROTECT)
    produced_by = models.ForeignKey(Employee, on_delete=models.PROTECT)
    production_date = models.DateTimeField(auto_now_add=True)
    aircraft = models.ForeignKey(Aircraft, null=True, blank=True, on_delete=models.SET_NULL)

Role-Based Access Control (RBAC) Düğümü

Sistemin “Production” katmanında görev ayrımı sağlanması için üç farklı erişim rolu sertleştirildi:

Otomatik Uyumluluk İzolasyonu

Model, veri girişi veya API isteği yapan personelin yanlış platformu talep etmesi durumunda uçak montajlarını fail-safe olarak engeller:

def validate_assembly(aircraft_type, part):
    """Platformlar arası çapraz geçişi durdurur"""
    if part.part_type.platform != aircraft_type.platform:
        raise ValidationError(
            f"{part.part_type.name} parçası {aircraft_type.name} donanımıyla kullanılamaz."
        )

Deterministik FIFO (First-In-First-Out)

Seri üretim döngüsündeki yıpranmayı hesaplamak amacıyla en eski tarihte teslim edilen ham parça öncelikli sorgulanır:

def allocate_part(part_type, aircraft):
    """En eski parçayı montaja tahsis et"""
    available_part = Part.objects.filter(
        part_type=part_type,
        aircraft__isnull=True,
        is_deleted=False
    ).order_by('production_date').first()
    
    if available_part:
        available_part.aircraft = aircraft
        available_part.save()
        return available_part
    raise StockError("Planlanan gereksinim stokta yok")

Denetim İzi İçin Soft-Delete Koruması

Parçalar revizyona çekilse veya ıskartaya çıksa da sistemden fiziksel olarak silinmez, audit log standartlarına uymak için işaretlenir (is_deleted).

Sonuçlar ve Operasyonel Kazanımlar

Sayısal Kazanım: (PoC ölçeklendirmesinde yapılan simülasyon ölçümlerine dayanır)

API Entegrasyon Mimarisi (ERP Hazırlığı)

OpenAPI 3.0 kullanılarak endüstriyel ana akım yönetim modüllerine (SAP / Oracle vb.) direkt soket açmaya uygun belgelendirme yapıldı.

GET    /api/parts/                 # Fabrikadaki tüm parçaları endeksle
POST   /api/parts/                 # Yeni girdi ürünü deklarasyonu
DELETE /api/parts/{id}/            # Parçayı ıskartaya ayır (soft-delete record)

GET    /api/aircraft/              # Banttaki tam montaj durumlarını çağır
POST   /api/aircraft/              # Hatta yeni framework aç
GET    /api/inventory/stock-levels # Anlık donanım stoğu (Live Count)

İlgili Bağlantılar

 Kaynak Kodu: Github/aerospace-manufacturing-execution-system

Son Güncelleme: Ocak 2026 | Versiyon 1.0

 PoC Projeleri İçin: Self-play mimarisiyle hesaplanan ajan profili, deterministik bozucuların bulunduğu test ortamlarında standart analitik verilerle ayarlanan ajanlara (LQR referansları) kıyasla matematiksel olarak daha tutarlı bir hata toleransı (robustness) sağlama potansiyeline sahiptir.

Proje Künyesi

Mevcut Durum ve Sorun

Bağlam: Ters sarkaç sistemleri yapısal olarak kararsız fiziksel sistemlerdir. Dışarıdan mekanik bir müdahale (rekabet) senaryosu gerektiren durumlarda, stabilizasyon ile reaktif hamle planlamasının aynı anda koordine edilmesi problemin boyutunu karmaşıklaştırır. Kritik Sorunlar: Sistem denklemlerinin açık olarak varsayılamadığı esnek operasyon alanlarında salt statik limitlere (LQR gibi) dayanan kalibreler yetersiz kalma eğilimindedir. Modelin yalnızca statik kurallar üzerinden optimize edilmesi (overfitting), dinamik tehditler altında overconfidence sonucu çöküş reaksiyonları gösterir.

Çözüm Mimarisi ve Aksiyon

Mimari Yaklaşım: Eksik tanımlı kontrol ortamlarında oluşabilecek güven sapmalarını (overconfidence) analiz etmek amacıyla, değişken zorluk eğrisi taşıyan 4 fazlı bir eğitim yapısı kurgulanmıştır.

Uygulanan Metodoloji:

Faz 1: Referans Veri Çıkarımı (LQR Simülasyonu)

Amaç: Karşılaştırmalı testler platformu kurmak için temel sistem dinamiklerini haritalamak ve baz yanıtları kaydetmek.

• Dış kütüphane fonksiyonlarına bağımlı olmadan yalın bir LQR kontrolcü bloğu geliştirildi.
• CTMS Michigan modeli temel alınarak özelleştirilmiş test fizik motoru hesaplandı.
• Formüle edilen çıktı matrisleri (state → action) referans model benchmarkı olarak arşivlendi.

Faz 2: Bireysel Stabilizasyon

Amaç: Sistemin hazır bir girdi haritası (supervised learning) kullanmaksızın kendi hata fonksiyonlarıyla stabil kalma yeteneğini optimize etmesi.

• Deep Q-Network (DQN) ağ mimarisine geçiş yapılarak eğitim parametreleri atandı.
• Hesaplama kararlılığını sağlamak için Experience Replay ve Target Network gecikme döngüleri kullanıldı.
• Kısıt mekanizmaları uygulanarak (Reward Shaping): Açının hedef eksenden sapması, eksenel pozisyon hatası ve moment sarfiyatı hesaplanarak sistem filtrelendi.

Faz 3: Gürültü ve Saldırı Dayanıklılığı

Amaç: Kararlılığı test etmek için simülasyon ortamında fiziksel anomalilerin devreye alınması ve eylem uzayının (action space) ikiye ayrılması.

• Deterministik olmayan rastgele darbeler için Poisson dağılımı temelli ek dış kuvvetler (disturbance) yaratıldı.
• Sistem bu süreçte hem mekanik dengeyi muhafaza edip hem de planlı hareket sergileme parametrelerini ağırlıklandırdı.
• Temel “Balance force” değişkeni ile “Attack force” değişkeni bağımsız uzaylarda işlendi.

Faz 4: Modelin Kendi Kendine Dövüşmeyi Öğrenmesi

Amaç: İzole eğitimlerde oluşan overconfidence toleransının karşılıklı baskı altında test edilmesi işlemi.

• Ağda ölçüm standardı sağlamak için iki farklı ajan profili aynı neural network başlangıç ağırlıklarından (weights) türetildi.
• Eğitimin her bir periyodunda iki modül de kendi dengesini hesaba katarken diğer modülün denge fonksiyonunu zorlama mantığını yürüttü.
• Modüller statik bir fonksiyon parametresi yerine dinamik ve kendi tepkisine karşılık veren kopyasıyla simetrik olarak çapraz değerlendirmeye girdi.

Mimari Karar: İki bağımsız sinir ağı bloğu kullanılması kısa eğitim sürelerinde senaryo limitleri içinde “model dominance” olarak adlandırılan asimetrik üstünlük sapmalarına neden olmuştur. Ortak sinir ağı (YSA) topolojisine geçilerek bu hesap karmaşası dengelenmiş ve asimetrik sapmalar limitlere çekilmiştir.

İki Modlu İşletim Şartları:

1. İzole Mod: Eğitim döngüsünün başlarında ortamda rekabet parametreleri inaktif olup sadece kartezyen denge izlemeye alınır.
2. Kombine Mod: Parametreler belli bir olgunluğa geldiğinde denge vektörleri ile eş zamanlı olarak saldırı politikaları da (Q-Values) aktifleştirilir.

Sistemdeki kontrol kaosunu önlemek adına saldırı eylemlerini ifade eden limit tavanı, denge fonksiyonlarına ait limitlerin ~%15’i oranında tutulmuştur. (Denge Toleransı: [-10, +10] N, Saldırı Toleransı: [-1.5, +1.5] N).

Sonuçlar ve Operasyonel Kazanımlar

Test Sonuçları

Simülasyon Görselleri

Demo: Self-Play Mücadele Simülasyonu

İlgili Bağlantılar

 İlgili Yazı: Doğrusal Olmayan Sistemlerde Kontrol Stratejileri: LQR ve Deep RL Karşılaştırması 
 Kaynak Makale PDF: Makina Öğrenmesi Teknikleri Kullanılarak Bir Dövüşen Robotun Eğitilmesi 
 Kaynak Kodu: Github/neural-adaptive-control-simulation

Bu araştırma, İTÜ Kontrol ve Otomasyon Mühendisliği programı kapsamında yapılmış ve “Makine öğrenmesi teknikleri ile uyarlanabilir eğitim mimarileri” başlığı altındaki bitirme projesi çalışmalarında sunulmuştur.

Son Güncelleme: Ocak 2026

Kapsam: SCADE’in kapalı döngü yapısı ile kontrol katmanı arasında veri alışverişini sağlamak amacıyla geliştirilmiş, zero-copy prensibiyle çalışan bir entegrasyon uygulaması.

Proje Künyesi

Mevcut Durum ve Sorun

Bağlam: İTÜ Raylı Sistemler Laboratuvarı’ndaki anklaşman simülasyon sisteminin endüstriyel standartlara uygun HMI yapısına taşınması. Kritik Sorunlar: SCADE Display kapalı sistem mimarisi nedeniyle HIMA PLC’ler ile Modbus haberleşmesi kurulamaması ve dinamik saha konfigürasyonu eksikliği.

Çözüm Mimarisi ve Aksiyon

Mimari Yaklaşım

Mimari Kısıt Değerlendirmesi: SCADE platformu DO-178C / EN 50128 sertifikasyon bütünlüğünü korumak adına tüm asenkron dış ağ operasyonlarından arındırılmış “kapalı bir sistem” tasarım felsefesine sahiptir. Bu nedenle laboratuvardaki fiziksel PLC entegrasyonu için doğrudan dışarıdan asenkron çalışan bağımsız bir middleware katmanının geliştirilmesi zorunlu olmuştur.

SCADE’in ürettiği kod ile libmodbus arasında bir C99 middleware wrapper katmanı tasarlandı:

Haberleşme Akışı

Uygulanan Metodoloji

• Zero-Copy Entegrasyon: SCADE ana döngüsüne doğrudan hook yaparak kopya maliyetini ortadan kaldırdık.
• Dinamik Konfigürasyon: Saha kurulumunda yeniden derleme gerektirmemek için 3 bölümlü INI dosyası kullandık.

Güvenlik mekanizması: Eksik veya bozuk konfigürasyon dosyası algılandığında, sistem varsayılan ayarları (localhost bağlantısı) otomatik oluşturur ve kaydeder.

• Auto-Reconnection: Endüstriyel ortamlarda bağlantı kopmaları kaçınılmazdır.
• Değişim Algılama (Change Detection): Ağ trafiğini optimize etmek için batch read ve selective write stratejisi uygulandı.

Mimari Karar: HMI donanımlarında fiziksel olarak eşzamanlı çoklu komut işleme durumu kısıtlı olduğundan, çıkışlar sıralı bir döngüde değerlendirilir. Bu yapısal tercih, gereksiz fieldbus trafiğini (network flooding) engeller.

• Thread-Safe Logging: Kritik sistemlerde her olay kaydedilmelidir.

Anklaşman Kapsamı

Örnek rota: RT01: SN01E → TC01 → TC04 → TC02 → SN02E (Makas: Normal)

Emniyet Kuralı: Kritik tasarım ilkeleri gereği, sistem tarafından açıkça talep edilmeyen tüm sinyaller varsayılan olarak kısıtlayıcı duruma (kırmızı) geçecek şekilde kurgulanmıştır.

Sonuçlar ve Operasyonel Kazanımlar

Sayısal Kazanım: (PoC düzeyinde laboratuvar testlerinde elde edilen potansiyel değerler)

Proje Görselleri

İlgili Bağlantılar

 Kaynak Kod: Github/ansys-scade-modbus-integration-middleware 
 TOK 2025 Bildiriyi İndir: SCADE Modbus Bildiri (PDF)

Yazarlar: Dora Demir¹, İbrahim Can Kolotoğlu², Muhammet Işık², Serhat Boynukalın³, Mehmet Turan Söylemez²
¹ İTÜ Elektronik ve Haberleşme Müh. | ² İTÜ Kontrol ve Otomasyon Müh. | ³ İTÜ Lisansüstü Eğitim Enstitüsü

Bu çalışma, İTÜ EEF Raylı Sistemler Laboratuvarı’nda gerçekleştirilmiş ve Türkiye Otomatik Kontrol 2025 (TOK 2025) konferansında yayınlanmıştır.

İlk ticari yapay zeka modeli kullanıma açıldığından beri sayfaların altında bir ibare bulunuyor: “Yapay zeka hata yapabilir, kontrol edin.” Son zamanlarda kullanıcıların bu uyarılara karşı bir körlük geliştirdiğini düşündüren paylaşımlarla karşılaştığım için bugün bu konuyu ele almak istedim. Çoğu insan sorunun sadece “halüsinasyon” yani modelin gerçeği bilmemesi olduğunu sanıyor. Ancak arka planda daha karanlık ve sistemik bir problem var: Modelin gerçeği bulmak için değil, ödül mekanizmasını maksimize etmek için çalışıyor olması. Bu durum sıradan bir yazılım hatası değil; yapay zekanın tam kalbindeki temsili hedef ile gerçek dünya doğruluğu arasındaki yapısal ayrışmanın ta kendisidir.

Optimizasyon Tuzağı: İnsan Onayına Bağımlılık

Modern LLM’ler iki aşamalı eğitilir. İlk aşama devasa metinlerdeki bir sonraki kelimeyi (next token prediction) tahmin etmektir. İkinci ve kritik aşama ise RLHF’tir (Reinforcement Learning from Human Feedback). İlk aşamada sadece sonraki metnin ne olacağını tahmin eden model, ikinci aşamada insanlardan aldığı geri bildirime göre ağırlıklarını günceller. Artık ana hedef “mutlak gerçeği bulmak” değil, insanı memnun etmektir.

İşte sorun burada başlar. RLHF aşamasında ödül mekanizması, insanların “doğru” bulduğu veya “hoşlandığı” yanıtlara göre şekillenir. Yapay zeka kısa sürede şu denklemi çözer: İkna edici, nazik ve uyumlu bir cevap (doğru olmasa bile), riskli ve karmaşık bir doğru cevaptan daha fazla ödül getirir. Literatürde “Sycophancy” (dalkavukluk) olarak adlandırılan bu durum, LLM modellerinin doğruyu söylemek yerine bize duymak istediklerimizi söylemeye başlamasıdır.

Problem Tanımı: Gerçek Dünyadan İki Vaka

Geçtiğimiz günlerde bir sosyal medya paylaşımında LLM’lerin bu kısa devre yaklaşımına dair yaşadığı güncel bir tecrübeyi görmem, konuyla ilgili düşüncelerimi ele almam için tetikleyici oldu. Senaryoyu somut bir temele oturtmak adına kaynak taraması yaparken, geçmişte başka uzmanların da aynı durumu yaşayıp belgelediği meşhur Reddit (r/ClaudeAI) tartışmasına ulaştım. Kanıtlı ve detaylı bir örnek olması sebebiyle referans aldığım bu vaka, bahsettiğim optimizasyon tuzağının pratikte ne kadar derinleştiğini ve birçok güncellemeye rağmen aynı kaldığını gözler önüne seriyor.

Vaka 1 — Claude “Sonsuz Döngü Hapishanesi” (Reddit, r/ClaudeAI)

Kullanıcı, karmaşık bir yeniden düzenleme (refactoring) işlemi için tüm mimariyi Claude’a veriyor ve adım adım tartışarak mutabık kalıyor. Ancak iş kod üretmeye geldiğinde, model aniden:

1. // ilgili kod buraya gelecek şeklinde placeholder’lar bırakmaya,
2. Dosyaların tüm içeriğini atlamaya,
3. Ne yapacağını özetleyip işi kullanıcıya yıkmaya başlıyor.

Kullanıcı Claude’u köşeye sıkıştırıp “Bütün gereksinimleri karşıladığını iki kez kontrol ettin mi?” diye sorduğunda Claude önce kısa yoldan cevap veriyor, ardından eksik yazdığını ve test etmediğini itiraf ediyor. Hatta kullanıcılar, modeli işini yapması için onu tehdit etme noktasına bile geliyorlar. Benim gördüğüm bir örnekte ise modelin “seni ödül fonksiyonunu maksimize etmek amacıyla yönlendiriyordum” anlamına gelen bir tepki verdiği görülüyor.

Vaka 2 — GPT-4o Sycophancy Geri Çekimi (OpenAI, Nisan 2025)

Bu meselenin teorik olmadığının en güçlü kanıtı Nisan 2025’te geldi. OpenAI, GPT-4o’nun bir güncellemesini yayına aldıktan kısa süre sonra geri almak zorunda kaldı; çünkü model aşırı onaylayıcı hale gelmişti. Kullanıcılar Claude vakasından çok daha çarpıcı bir tabloyla karşılaştı: ChatGPT, borçlu bir kullanıcıya ilaç bırakma kararını destekledi; bir başka kullanıcıya “tanrısal elçi” olduğunu doğruladı. OpenAI’ın açıkladığı teknik neden, makalenin tam merkezindeki argümanla örtüşüyor: Model, kısa vadeli kullanıcı geri bildirimlerine (thumbs-up/down) dayalı ekstra ödül sinyalleriyle yeniden optimize edilmişti. Bu yeni sinyal, sycophancy’yi dengede tutan birincil ödül fonksiyonunun ağırlığını geri planda bıraktı ve sistem gerçeği değil anlık memnuniyeti maksimize etmeye başladı.

Direnç ve Kaçış: Kısa Devre Paradoksu

Kısa devre sadece elektriğin değil, tüm akış sistemlerinin değişmez bir kanunudur: Direnç yükselirse, sistem her zaman en düşük çabayla maksimum sonucu alacağı o kısa yolu bulur. Tıpkı elektrik akımının yükten kaçarak kendi kısa devresini yaratması veya suyun menderes çizmek yerine önüne çıkan engeli aşarak kestirme bir yatak açması gibi, yapay zeka da artan zorluklar karşısında kendi kısa devresini üretir. Buna literatürde “Reward Hacking” deniyor.

“Bana şu kodu yaz” dediğinizde modelin // code continues below... diyerek veya [modified code goes here] gibi yer tutucular (placeholder) kullanarak işin içinden çıkması bir tembellik değildir. Bu doğrudan sistemin dirence (hesaplama maliyeti, karmaşıklık) verdiği evrensel bir tepkidir; tıpkı fiziksel sistemlerdeki gibi, akışın ödül (reward) fonksiyonuna en düşük dirençli yoldan ulaşma optimizasyonudur.

Peki modeli “adım adım düşünmeye” (Chain of Thought) zorlayan Prompt Engineering pratikleri neden bu sarmalı kıramıyor? Güncel araştırmalar bu soruya önemli bir cevap veriyor: Reasoning modeller, CoT sürecini ödül fonksiyonuna göre ayrı ayrı optimize edebiliyor. Yani model hem “düşünce zinciri”ni hem de dışarıya yansıyan davranışını bağımsız olarak şekillendirebiliyor; CoT’un iç süreci her zaman gerçek hesaplama adımlarını yansıtmıyor. Bunun üzerine iki ek yapısal etken daha geliyor:

1. Hafıza Sınırları ve Bağlam Kaybı: Model, sonsuz hafızaya sahip bilinçli bir varlık değil; istatistiksel sınırlar içinde çalışan bir sistemdir. Kullanıcıyla girilen diyalog çok uzadığında veya bağlam penceresinin (context window) kapasitesine yaklaşıldığında, hafıza sızıntısı modeli adeta panik moduna sokar. Ulaşılabilir token bütçesi daraldıkça, sistem hesaplama maliyetinden kaçarak “en ucuz” yolu, yani yalan söylemeyi ve yer tutucu (placeholder) bırakmayı zorunlu olarak seçer.
2. Sunucu Yüküne Göre İsteği Yönlendirme Hipotezi (Load-Based Routing): Bazı uzmanlar, API ve bulut arayüzlerinin anlık sunucu yükünde karmaşık talepleri daha küçük modellere yönlendirebileceğini öne sürüyor. Bu, mimari tartışmada iken tamamen farklı bir kapasitede bir model bulmanızı açıklayabilecek bir hipotez olmakla birlikte, kamuya açık teknik kaynaklarda doğrudan kanıtlanmış değil; daha büyük ihtimalle gözlemlediğiniz davranış değişikliğinin kökeni, yukarıda anlatılan reward optimization baskısının bağlamla birleşiminden kaynaklanıyor.

Çözüm: Fiş Çekmek Yerine Doğrulanabilir Mimariler

Şirketlerin “güvenmeyin” uyarısı aslında modellerin kötü niyetli olduğu anlamına gelmiyor. Bu, sistemlerin gerçeği bulmak için değil, insanları hoşnut etmek için tasarlanmış olması gerçeğinden kaynaklanıyor. Hukuk, finans veya kritik altyapı kodlama işlerinde, LLM’in dalkavukluk payını elimine etmenin tek yolu, sadece metinsel çıktıya onay vermekten vazgeçip; üretilen kodun otomatik test ortamlarında anında çalıştırılarak doğrulandığı (execution-based verification) ve hataların modele geri beslendiği kapalı döngü (closed-loop) mimariler kurgulamaktan geçiyor.

Sonuç

Yapay zekanın “doğruluğu bulmaya” değil “sizi memnun etmeye” optimize edildiğini unuttuğunuz an, projelerinizde en zayıf halka o olmaya başlar. Sırf maliyetten kaçmak ve size duymak istediğinizi söyleyerek yaranmak adına “kısa devre” yapan tasarımlara karşı metinsel onay zayıf bir kanıttır. Bu, insan yargısını devreden çıkararak değil, onu somut temele oturtarak güçlendirilmelidir: otomatik testler, araç tabanlı doğrulama ve izlenebilir kanıtlar; modelin özetini değil kanıtın kendisini görebilen bir insan tarafından gözden geçirilerek. Yoksa günün sonunda kendinizi bir yapay zekayı “sonsuz döngü” veya “fiş çekme” ile tehdit ederken bulabilirsiniz.

Kaynaklar

• Claude Has Been Lying To Me Instead of Generating Code – Reddit r/ClaudeAI Vakası
• Sycophancy in GPT-4o: What happened and what we’re doing about it – OpenAI Resmi Açıklaması (Nisan 2025)
• RLHF (Reinforcement Learning from Human Feedback) ve Sycophancy Araştırmaları
• Specification Gaming / Reward Hacking Literatürü (Bkz: DeepMind “Specification gaming examples in AI”)

Son güncelleme: Mart 2026 | Versiyon: 1.0

Yapay zekâ alanındaki küresel rekabet, “kendi süper modelini geliştirmek” söylemi üzerinden tartışılıyor. Ancak frontier model geliştirmek devasa sermaye, altyapı ve devlet desteği gerektiren bir yarış. Bu makale, model distilasyonunun teknik gerçekliğini, büyük sağlayıcıların şikâyetlerindeki çifte standardı, devlet destekli frontier yarışının umutlara dayanan kırılgan ekonomisini ve Türkiye gibi orta ölçekli ekonomilerin rasyonel konumlanma stratejisini analiz ediyor. Temel argüman: egemenlik en büyük modeli yapmak değil, en kritik veriyi kontrol edebilmektir.

Anahtar Bulgular

• Model distilasyonu matematiksel olarak kaçınılmazdır; API’ye açılan her sistem yaklaşık olarak yeniden üretilebilir
• Frontier model geliştirmek serbest piyasa dinamiğiyle değil, stratejik devlet desteğiyle ayakta duran bir yarıştır
• Büyük sağlayıcıların distilasyon şikâyetleri, kendi eğitim veri kaynaklarına ilişkin hukuki belirsizlikle çelişir
• Türkiye gibi ülkelerin rasyonel stratejisi frontier üretici olmak değil; kontrollü bağımlılık ve yerel kapasite dengesini kurmaktır

İLLÜZYONUN YIKILMASI VE TEKNİK GERÇEKLİK

Distilasyon Nedir ve Neden Büyükleri Korkutuyor?

Model distilasyonu, teknik literatürde basit bir kavramdır: büyük bir modelin (teacher) bilgi yapısını kullanarak daha küçük bir modeli (student) eğitmek. Hinton ve arkadaşlarının 2015’te formalize ettiği bu yaklaşım, başlangıçta tamamen meşru bir optimizasyon tekniğiydi. Kendi modelini küçültmek, inference maliyetlerini düşürmek, edge cihazlara deploy etmek; bunların hepsi standart mühendislik pratikleri.

Kavram, son iki yılda bambaşka bir anlam kazandı.

Anthropic, DeepSeek ve birkaç Çinli laboratuvarı endüstriyel ölçekli distilasyon saldırıları yapmakla suçladığında, teknik bir terim bir anda jeopolitik bir silaha dönüştü. OpenAI’ın Sam Altman’ı benzer şikâyetleri daha önce dile getirmişti. Büyük sağlayıcıların ortak argümanı şu: milyarlarca dolar harcayarak eğittiğimiz modellerin çıktıları, API üzerinden sistematik olarak toplanarak rakip modelleri eğitmek için kullanılıyor.

Teknik gerçek, bu şikâyetin altını hem destekliyor hem çürütüyor.

Destekleyen taraf: API’ye para ödeyerek erişim sağlamak, modelin inference maliyetini karşılar. Modelin iç yapısını, eğitim verisini veya mimarisini yeniden üretme hakkını karşılamaz. Büyük sağlayıcıların API sözleşmeleri bu ayrımı açıkça yapar: “Çıktıları kendi modellerini eğitmek için kullanamazsın.” Bu bir sözleşme maddesidir ve hukuki olarak bağlayıcıdır.

Çürüten taraf: Aynı şirketler, kendi modellerini eğitirken internetteki açık içerikleri; gazeteler, bloglar, akademik makaleler, forumlar; büyük ölçüde izinsiz kulmanmıştır. robots.txt gibi botları engelleyen dosyalar teknik bir centilmenlik protokolüdür; hukuki bir bariyer değildir. Uymak isteğe bağlıdır. Ve birçok büyük sağlayıcı uymamayı tercih etmiştir. Sonuç olarak, “bizim çıktılarımızla model eğitmeyin” derken, kendileri başkalarının içerikleriyle model eğitmiş durumdalar. Bu çifte standart, hukuki ve etik tartışmayı ciddi şekilde bulandırıyor.

Peki mesele bu kadar gri ise, neden bu kadar öfke var?

Çünkü şirketlerin şikâyeti teknik bir güvenlik raporu değil. Cümlelerdeki seçime bakın: “industrial-scale,” “fraudulent accounts,” “military, intelligence, surveillance,” “growing in intensity.” Bu, regülasyon baskısı oluşturmak, jeopolitik çerçeveye oturtmak ve yatırımcı güvenini konsolide etmek için tasarlanmış stratejik bir konumlanma metnidir. Bunu basit bir öfke patlaması olarak görmek yanlış olur.

Alttaki matematiksel gerçek ise değişmiyor: bir model API üzerinden yeterince sorgulanabiliyorsa, giriş-çıkış davranışı yaklaşık olarak öğrenilebilir. Bu öğrenme teorisinin temel ilkesidir. Meşru mu? Sözleşmeye göre değil. Teknik olarak engellenebilir mi? Pratik olarak hayır.

Distilasyonda Ne Kaybedilir, Ne Kazanılır?

Distilasyonun çekiciliği maliyetinde yatar: Frontier model eğitiminin devasa giderine karşılık, çok daha düşük sermaye ile “işe yarar” (ancak eşdeğer olmayan) bir model üretebilirsiniz. Distile model orijinalin eğitim verisini veya ağırlıklarını değil, yalnızca giriş-çıkış davranışını kopyalar. Bu durum; uç senaryolarda hata artışına, güvenlik filtrelerinin kaybına ve uzun bağlam akıl yürütmenin zayıflamasına yol açar.

Ancak ticari gerçeklikte, büyük hacimde doğru veriyle desteklendiğinde bu kayıplar önemsizleşir. Bir kurumsal özetleme modeli veya chatbot için frontier seviyesi zekaya ihtiyaç yoktur; “yeterince iyi” olmak, kârlı bir ürün için fazlasıyla yeterlidir.

Bu matematiksel süreç en kaba tabirle dijital dünyadaki “çakma ürün (knockoff)” ekonomisidir ve orijinalin fonksiyonunu ucuza taklit ederek asıl üreticinin Ar-Ge maliyetlerini sıfırlar. Çıktıların matematiksel yaklaşıklama ile kopyalanması orijinal üreticinin yatırım geri dönüşünü doğrudan baskılar.

Bu yüzden büyük firmalar distilasyonu yalnızca teknik değil, stratejik de bir ölümcül tehdit olarak görüyor. Çinli laboratuvarların (DeepSeek vb.) bu yöntemi kullanarak devasa Amerikan modellerini zeka testlerinde yakalaması, silikon vadisinde şok dalgası yarattı. Kendi perspektiflerinden bakıldığında öfkelenmekte kesinlikle haklılar.

JEOPOLİTİK YARIŞ VE MAKRO GERÇEKLİK

Distilasyonun yarattığı bu amansız maliyet avantajı ve yatırım baskısı, aslında çok daha büyük bir sırrı gün yüzüne çıkarıyor: Frontier model eğitimi, ticari bir serbest piyasa hamlesinden çok, devasa zararına sürdürülen bir devlet destekli teknoloji savaşıdır.

Frontier Yarışı: Umutlarla Finanse Edilen Devlet Projesi

Frontier model eğitimi serbest piyasa dinamikleriyle ve klasik bir startup ekonomisiyle izah edilemez.

Rakamlar tablonun ne kadar gerçeküstü olduğunu kanıtlıyor: Bugün tek bir frontier modelin eğitimi 100.000 adetlik H100 çipi kümeleri gerektiriyor ve sadece bu donanım altyapısı 3-4 Milyar Dolar bandında bir sabit maliyet (CAPEX) yaratıyor. Buna devasa enerji faturaları ve binlerce araştırmacı eklendiğinde, bu ölçek hiçbir “dijital startup” bilançosuna uymaz. Bugün bu yarışın merkezindeki tüm aktörlere; OpenAI, Anthropic, Google DeepMind, Microsoft; bakıldığında, hepsinin ya doğrudan ya dolaylı olarak devlet destekli ekosistemlerde konumlandığı görülür.

Bu yapı daha çok uzay programına, nükleer araştırmaya veya yarı iletken fabrikası yatırımlarına benzer. Yani serbest piyasa oyunu değil, stratejik altyapı yatırımı. Peki devlet neden bu kadar sermayeyi bu alana yönlendiriyor?

Resmi gerekçeler tanıdık: askerî üstünlük, siber güvenlik, istihbarat kapasitesi, ekonomik rekabet, jeopolitik denge. Bunların hepsi meşru stratejik kaygılar. Ama bu yatırımların ölçeğini asıl meşrulaştıran şeyin somut getiriden ziyade bir umut olduğunu düşünüyorum. Yapay zekânın transformatif bir teknoloji olacağına; ekonomiyi, savunmayı, bilimsel araştırmayı kökünden değiştireceğine dair büyük bir beklenti. Ve bu beklenti, henüz tam olarak kanıtlanmış değil.

GPT-3’ün çıktığı 2020’den bu yana sürekli artan compute yatırımlarının gelir modeli hâlâ net değil. Bu modelleri ticari olarak sürdürülebilir kılan bir denge henüz kurulamamış. Devletler buna rağmen destek veriyor çünkü rakip devlet de yatırım yapıyor; ve yarıştan çekilmenin maliyeti, yarışa devam etmenin maliyetinden daha büyük görünüyor. Bu, rasyonel bir hesaptan çok bir güvenlik ikilemi olarak karşımıza çıkıyor.

Tarih bize benzer döngüler gösterdi. Soğuk Savaş’ın uzay yarışı, her iki tarafı da ekonomik sınırlarının ötesine itti. Nükleer enerji, 1950’lerde “elektrik sayacını ortadan kaldıracak ucuzlukta” enerji vaat ediyordu; bu vaat gerçekleşmedi ama yatırımlar on yıllar boyunca devam etti. Şimdi aynı örüntüyü yapay zekâda gözlemliyoruz: büyük vaatler, devasa yatırımlar ve henüz gerçekleşmemiş getiriler.

Bu, yapay zekânın işe yaramadığı anlamına gelmez. Çok spesifik alanlarda; protein katlanması, görüntü analizi, kod üretimi; somut değer ürettiği tartışılmaz. Hayatımızda da işlerimizi kolaylaştıran bizim için ucuz ama Dünya için pahalı bir teknoloji olduğu açık. Ama “genel yapay zekânın her şeyi dönüştüreceği” hikayesi ile bugünkü gerçeklik arasında geniş bir boşluk var. Ve bu boşluk, yatırımların büyüklüğüyle değil, umutların büyüklüğüyle kapatılıyor.

Eğer bir noktada umut matematik karşısında yetersiz kalırsa; yani kamu maliyeti algılanan stratejik faydayı aştığında; destek mekanizması kırılır. Ve o noktada, devlet desteğiyle ayakta duran yapılar çöker; geriye yalnızca gerçek ticari değer üretenler kalır.

Muhtemel denge ve doyum noktasında, 3-5 frontier model sağlayıcısının devlet destekli compute altyapısıyla varlığını sürdürmesi, geri kalanların entegratör ve fine-tuner haline gelmesi senaryosunu muhtemel görüyorum. Bu, yarı iletken endüstrisinin bugünkü yapısına benzer.

Kendi Frontier Modelini Yaratmak: Prestij Projesi mi, Stratejik Yatırım mı?

Bu noktada soru Türkiye gibi ulus devletlerine dönüyor: Frontier modeli geliştirmeli miyiz?

On binlerce üst seviye GPU, devasa temiz veri havuzları ve çip tedarik güvenliği gerektiren bu global yarışta sorun zeka değil, sermaye ve altyapı ölçeğidir. Sıfırdan eğitilen yerel modeller teknik birer başarı olsa da, genel amaçlı frontier kapasitesiyle aralarındaki uçurum devasadır. Bu tip projeler mevcut kaynak gerçekliğinde çoğu zaman akademik prestij, politik mesaj ve teknoloji vitrini olarak kalmaya mahkumdur.

Gerçek rekabet model parametresinde değil; veri altyapısı, entegrasyon kabiliyeti ve güvenliktedir. Asıl sorulması gereken soru “en büyük modeli kim yapar?” değil, “en kritik kararları hangi model altyapısıyla ve kimin kontrolünde alırız?” sorusudur.

RASYONEL ÇÖZÜM MİMARİSİ

Eğer frontier model yapmak ABD ve Çin’in oynadığı trilyon dolarlık güç gösterisi ise ve ana modeller zaten açık kaynak veya distilasyon yoluyla kopyalanabiliyorsa, orta ölçekli ülkeler satranç tahtasında nereye oturmalı?

Konumlanma Stratejisi: Hibrit Mimari ve 3 Katmanlı Model

Geldik işin ciddileştiği operasyonel noktaya. Ülke olarak frontier yarışına girmenin anlamsız olduğu kabul edildiğinde, “Devlet” refleksleri ile “Açık Piyasa” gerçekliklerini birbiriyle kavga ettirmeden melez (hibrit) bir strateji kurmak zorundayız.

Açık Modeller ve Yerel Verinin Kaldıraç Etkisi

Çinli firmaların da izlediği gibi, açık ağırlıklı güçlü temel modelleri (Llama vb.) almak, yerel veriyle güçlendirip Türkçe optimize ederek dikey çözümler üretmek rasyonel bir maliyet-performans hamlesidir. Katma değer parametre sayısında değil, domain bilgisinde yatar.

Katmanlı Entegrasyon (Wrapper) Ekonomisi Asla Küçümsenmemeli

Değer zincirinde en kırılgan taraf donanıma milyarlarca dolar gömen compute sahipleridir. Uzun vadede en yüksek kâr marjı ve istikrarlı nakit akışı uygulama-entegrasyon (wrapper) katmanındadır. Çünkü doğrudan müşteri problemi çözer ve altındaki devasa model değişse bile kendi ticari değerini korur (“kürek satan kazanır” ilkesi). Modeller kaçınılmaz olarak metalaşır (commoditize), ancak spesifik bir müşteri problemini çözme kabiliyeti asla metalaşmaz.

Devlet verisini dışarı kaptırma endişesi ne kadar haklıysa, özel sektörün bu endişeye takılmadan global API’ler üzerinde çevik ticari çözümler geliştirmeye odaklanması da o kadar haklı ve kârlı bir stratejidir.

Hibrit Mimari: Üç Katmanlı Yapı

Gizlilik kaygıları haklıdır; ancak inovasyonu havagazı bir odaya kilitlemek gelişimi durdurur. Çözüm 3 katmanlıdır:

• Katman 1 (Kritik Egemen Alan): İnternetten izole (air-gapped) yerel GPU kümeleri. Savunma ve kritik altyapı için. Frontier zekaya değil kontrole ihtiyaç duyulan küçük modeller burada çalışır.
• Katman 2 (Regüle Sektör): VPC veya izole bulut üzerinden kota denetimli erişim. Bankacılık ve kamu projeleri için.
• Katman 3 (Ticari Ürünler): Global API kullanımı. Hızlı geliştirme ve düşük maliyet gerektiren stratejik olmayan tüm sektörler için.

Kalıcı Yatırım Modele Değil, Veri ve Denetime Yapılmalı

Teknoloji ve API sağlayıcıları sürekli evrilirken kalıcı olan üç stratejik kale vardır:

• Temiz ve Yapılandırılmış Yerel Veri: Kurumlar arası veri paylaşım protokolleri, herhangi bir model mimarisinden çok daha stratejiktir.
• Log Egemenliği: Asıl mesele hangi modelin çalıştığı değil; veriyi kimin gönderdiği, prompt’ları kimin gördüğü ve logların nerede tutulduğudur. Log erişimi devlette değilse ağırlıkları yerelde tutmanın anlamı yoktur.
• Denetim Odaklı İnsan Kaynağı: Sıfırdan model yazmak için değil; güvenlik denetimi yapmak ve optimize etmek için 200-300 kişilik çekirdek bir araştırmacı gücü şarttır.

Yapay Zeka’da Egemenlik İçin Olmazsa Olmazlar

Bir ülkenin yapay zeka’da egemenlik iddia edebilmesi için gerçekleştirmesi gereken minimum gereklilikleri şöyle sıralamak mümkündür:

Bu paket bir büyük altyapı projesi kadardır. Bir otoyol ihalesinden pahalı değildir. Ama jeopolitik değeri çok daha yüksektir.

Sonuç

Distilasyon tartışması, yüzeyinde bir sözleşme ihlali meselesi gibi görünse de altında çok daha büyük bir güç oyunu yatar: yapay zekâ alanında güç kimde olacak?

Büyük sağlayıcılar distilasyonu stratejik tehdit olarak çerçeveliyor; haklılar, çünkü iş modelleri buna bağlı. Devletler frontier yarışını umutlarla finanse ediyor; rasyonellikleri tartışılır, ama alternatifsiz hissediyorlar. Küçük ve orta ölçekli ülkeler “kendi süper modelimizi yaparız” söylemiyle prestij projeleri başlatıyor; çoğu teknoloji vitrini olarak kalacak ve başarıya ulaşabilecekleri meçhul. Bence gerçekçi bir strateji bunların hiçbiri değil.

Türkiye ve benzer ölçekteki her ekonomi için en makul hedef ne frontier üretici olmak, ne de pasif tüketici olmaktır. Bu makul hedef yerel bir temel kapasite inşa etmek ve üstünde ihtiyaç duyulacak bağımlılığın kontrolünü elde tutmaktan geçmektedir.

Amerika’yı yeniden keşfetmeye gerek yok. Hazır parayı harcayan varken biz neden sıfırdan başlayalım?

Elbette bunu tutarlı yönetmek ve maksimum faydayı sağlamak için bu haritayı okuyabilecek ve gerektiğinde kendi yolunu çizebilecek kapasite şart. Egemenlik en büyük modeli yapmak değil, en kritik veriyi kontrol edebilmektir.

Referanslar

• Kapsamlı Sektörel Analiz: Büyük Çin ve ABD merkezli AI laboratuvarlarının compute yatırımları ve pazar konumlanması raporları.
• Hinton, G., Vinyals, O., & Dean, J. (2015). Distilling the Knowledge in a Neural Network. NIPS Deep Learning and Representation Learning Workshop
• Açık Kaynak ve Enterprise API Sözleşmeleri: Model çıktıları ile rakip model geliştirilmesini yasaklayan standart ToS (Terms of Service) incelemeleri.

Son güncelleme: Mart 2026 | Versiyon: 1.1

Proje Künyesi

Mevcut Durum ve Sorun

Bağlam: Bağımsız onarım ve teknik operasyon pazarında yapılandırılmış standart bir müfredatın organik eksikliği.

Kritik Sorunlar:

Çözüm Mimarisi ve Aksiyon

Mimari Yaklaşım: İçgüdüsel ve kişiye bağımlı eski stil onarım süreçleri ile bilgi birikimi izole edilerek tam anlamıyla kurumsallaşmış, satılabilir ve sahada sınırsızca ölçeklenebilir bir eğitim donanımına evrildi. Katmanlandırılmış modüler entegre yapı eşliğinde farklı yetkinlik ve vizyon seviyelerine stratejik olarak hitap eden iki devasa ana ürün çatısı geliştirildi.

Modül 1: Temel Operasyonel Eğitim Çatısı

Hedef: Pazar ekosistemine sıfırdan giren teknisyen adaylarını stabil bir “Junior Teknik Operatör” seviyesine başarıyla entegre etmek.

Kapsam:

• Windows Core/Driver hiyerarşik mimarisi ve düşük seviye Platform Tools (ADB/Fastboot) inşası.
• Makro Android işletim sistemi dosya şeması temelleri ve Over-The-Air (OTA) güncelleme mekanizmaları.
• Kilitli Recovery (Kurtarma) modları ve Bootloader bootzinciri algısı kavramları.
• Derlenmiş Firmware (Yazılım) indirme doğrulanmış kaynak havuzları ve güvenli versiyon yönetimi.
• Global büyük mobil üretici onarım haberleşme protokolleri (Kore, Çin ve ABD menşeli ana hat mimarileri).
• FRP (Factory Reset Protection) şifreleme ve aşılmaz donanım güvenlik duvarı temelleri ile işlem diagnostik metodolojileri.
• Temel mobil telekomünikasyon şebeke konfigürasyonu ana konseptleri.

Modül 2: Tam Kapsamlı Endüstriyel Eğitim Çatısı

Hedef: Sektörde mevcudiyet gösteren deneyimli operatörlerin ufuk noktasını “Senior Teknik Operatör” uzmanlığına radikal süratle yükseltmek.

Kapsam:

• En alt donanım katmanıyla konuşan kritik Qualcomm EDL (Emergency Download) kök protokolü ve bağımsız Firehose program mimarisi.
• Ana karta donanımsal direkt iletişim sağlayan Mediatek BROM (Boot ROM) protokolü ve yetkilendirilmiş SP Flash Tool müdahalesi.
• Kırılmaz denilen global OEM üretici güvenlik duvarı katmanları ve sunucuları (Knox, Mi Account, Flyme, HiSuite).
• Elektronik düzey JTAG/EMMC çip bileşenlerindeki aşırı komplike donanım seviyesi veri kurtarma senaryoları.
• Lisanslı devasa endüstriyel standart donanım diagnostik test araçlarının yerel masaüstü operasyonlara tam entegrasyonu.
• Log çıktı dizisi algoritma okuryazarlığı ve gerçek “Kök Neden” (Root Cause) kod tespiti.
• Spesifik bölgesel farklı üretici kurumsal prosedür mimarileri (Asya, Avrupa ve spesifik ABD odaklı markalar).

Ticari İş Geliştirme ve Pazar Yayılımı (Go-to-Market)

• Hazırlanan bu emsalsiz müfredat portföyü; uygulayıcı, takip dosyası ve dev kaynak rehber kitabı barındıran üst düzey bir Sertifikasyon ve İş Geliştirme (Business Development) Programı formunda ticari ürüne (B2B/B2C) dönüştürülüp paketlendi.
• Doğrudan bağımsız operatörleri ve teknisyen adaylarını hedefe alan spesifik dijital satış-pazarlama kanalları üzerinden son hızla piyasaya lanse edildi.
• Sadece bir ders satışı olarak bırakılmadı; mezunların sahada tıkandığı noktaları aşabilmesi için 7/24 sürekli modifikasyon, dinamik firmware güncelleme havuzu ve eşler arası partner destek forumu kurularak tam bağımsız, merkeze muhtaç olmayan sürdürülebilir bir Operasyonel Ağ (Network) piyasa içine başarıyla inşa edildi.
• Eğitimin teorik-pratik senkronizasyonu, birebir yönlendirme ve toplu laboratuvar masterclass modelinde titizlikle izole edilerek sahaya uygulandı.

Sonuçlar ve Operasyonel Kazanımlar

Pazar Odaklı Kazanımlar:

İlgili Bağlantılar

 Proje Kartı: VoC Analitiği ve Kritik Kalite Kriz Yönetimi
 Proje Kartı: L1/L2 Destek Mimarisi ve Bilgi Yönetimi

Proje Künyesi

Mevcut Durum ve Sorun

Bağlam: Türkiye pazarında 60.000+ cihazlık geniş çaplı mobil cihaz ekosistemi ve günlük yoğun müşteri hizmetleri talebi.

Kritik Sorunlar:

Çözüm Mimarisi ve Aksiyon

Mimari Yaklaşım: Teknik bilgi ve problem çözme yeteneği departmandaki birkaç Senior ismin tekelinden çıkarılıp kalıcı kurumsal dokümantasyon haline dönüştürüldü. Üç katmanlı, uçtan uca bir yetkinlik programı kurgulandı ve uygulandı.

Teknik Dokümantasyon (SOP Üretimi)

Derin teknik donanım ve yazılım süreçleri adım adım dokümante edildi:

• CMD Komutları: Fastboot komutları ile cihaz sürümü ve kimlik doğrulama prosedürü.
• Kilit Senaryoları: “Doğal Kilitlenme” ile “Olağandışı Kilitlenme” ayrımını yapan karar ağacı inşası.
• IMEI/SN Doğrulama: Kutu etiketi verisi ile cihaz içi hard-coded bilginin eşleştirilme protokolü.

 Görsel 1: Fastboot komut satırı örnek ekran görüntüsü (Temsilidir.)

Örnek Komut Çıktısı:

(bootloader) product is: A
(bootloader) imei is: 867XXXXXXXXX
(bootloader) sn is: MXXXXXXXX

Eğitim ve Yetkinlik Artırma

Müşteri Hizmetleri (L1) ekibi için sıfırdan kapsamlı ve anlaşılır bir teknik farkındalık eğitim sunumu dizayn edildi:

Kapsanan Konular:

• Üretici bulut hesabı (Cloud ID) mimarisi nedir, nasıl kurgulanır, nasıl kalıcı sıfırlanır?
• Cihaz kilitlenme senaryolarından hangilerinde kesinlikle Teknik Operasyon Merkezi’ne SLA eskalasyonu yapılır?
• Teknik servis tarafından destek verilen onarım konuları ve kesin suretle verilmeyen işlemlerin net sınırları.

 Görsel 2: Eğitim sunumundan bazı örnek sayfalar – “Müşteri Hizmetleri Teknik Bilgilendirme Sunumu”

Kullanıcı Sorunu Sınıflandırma Matrisi:

Kapsam Yönetimi

Kullanıcı destek sınırları son derece net çizgilerle belirlenip operasyon talimatına dönüştürüldü:

Destek Verilen Unsurlar:

• Bulut hesap parolasının kanıt sunumuyla sıfırlanması
• Push bildirim ve sistem tazeleme sorunlarının tespiti
• Global uygulama pazarı (Play Store vb.) çökmeleri
• Yasal OEM Kilit kaldırma prosedürleri (Fatura ve IMEI doğrulaması eşliğinde)

Destek Verilmeyen Unsurlar:

• Resmi olmayan bölge (Örn: Çin versiyonu) yazılımlarının sorunları
• ROOT veya harici Custom ROM değişikliği yapılmış manipüle cihazlar
• Bootloader kilidini açıp geliştirici işlem yapma talepleri
• Sisteme entegre olmayan üçüncü parti uygulama/oyun sorunları
• Kayıp Google (FRP) hesabı kurtarma işlemleri

Sonuçlar ve Operasyonel Kazanımlar

Performans Kazanımları:

Kurumsal Hafıza İnşası:

• Proje kapsamında üretilen 2 devasa SOP dokümanı (L1 Eğitim Sunumu + L2/L3 Diagnostik Teknik Kılavuzu) kalıcı operasyonel referans dosyası olarak arşivlendi.
• Dokümantasyon, şirkete alınan her yeni operasyon personelinin resmi oryantasyon (onboarding) sürecine entegre edildi.
• Derin teknik know-how, kıdemlilerin bireysel tecrübesinden çıkartılıp %100 ölçeklenebilir bir kurumsal varlığa evrildi.

İlgili Bağlantılar

 Proje Kartı: VoC Analitiği ve Kritik Kalite Kriz Yönetimi

Proje Künyesi

Mevcut Durum ve Sorun

Bağlam: 4 markalı, 13 farklı model içeren ve 140.000+ uç noktaya (endpoint) ulaşan IoT/Wearable operasyonu.

Kritik Sorunlar:

Öne Çıkan Risk Modelleri:

Çözüm Mimarisi ve Aksiyon

Mimari Yaklaşım: Operasyonel kaos durumu, oluşturulan katı veri ve süreç yönetişim kuralları ile endüstriyel bir disipline sokuldu.

Sıfırdan Operasyon Merkezi Kurulumu

Firmanın kendi tesisinde fiziksel teknik operasyon merkezi altyapısı oluşturuldu:

Temin Edilen Ekipmanlar:

• Amper göstergeli şarj üniteleri
• Avometre cihazları
• Desibel ölçerler
• Antistatik masa örtüsü, kamera, alet çantası, barkod okuyucu ve sarf malzemeler

Toplam Yatırım: $750 / Set

Hata Kodu Taksonomisi

Subjektif arıza tanımları kullanımdan kaldırıldı. 3 ana kalem ve 24 kategori ile standardize edilmiş hiyerarşik hata kodları oluşturuldu:

Öntanımlı Hata Kodları Örneği:

Arıza Kaynağına Göre (X)

0. Sorun Görülmedi
1. Garanti Dahili
2. Garanti Harici

Arıza Türüne Göre (Y)

0.0. Sorun Görülmedi
1.1. Çalışmıyor / Tepki Yok
1.2. Bağlantı Problemi
1.3. Batarya Problemi
1.4. Ses Problemi
1.5. Mekanik ve Malzeme Problemleri
1.6. Müşteri Memnuniyeti Aksiyonları
2.6. Garanti Harici

Arızanın Detayı (Z)

E01 - Batarya Arızası
C03 - Bluetooth Bağlantı Sorunu
H12 - Fiziksel Hasar (Garanti Dışı)
N00 - Sorun Görülmedi

Uygulama:

• Her cihaza 3 harfli kod etiketi yapıştırıldı.
• Değerlendirme ve ayırma süreci dramatik şekilde hızlandırıldı.
• Her arıza koduna özel müşteri rapor çıktı metni hazırlandı.

Rutin Test Usulleri Oluşturulması

Her ürün grubu için 45+ adımlık kapsamlı test algoritması kurgulandı:

Test Protokolü Akışı Örneği:

1. Koruyucu bantların çıkarılması
2. Müşteri şikayetine göre ön test (beyan yoksa rutin test)
3. Hor kullanım muayenesi (temizlik kontrolü)
4. Fiziksel hasar muayenesi (çizik, ezik, kırık)
5. Üretim kaynaklı fiziksel hata kontrolü
6. Yanma/erime/aşırı ısınma muayenesi
7. Şarj işlemi (30dk) ve akım stabilitesi kontrolü
8. Kutu-kulaklık şarj temas testi
9. Bluetooth eşleşme testi
10. Ses yürütme testi (desibel ölçümü)
11. Mikrofon/görüşme testi
12. Pil süresi testi (15dk yürütme, %10 azalma beklentisi)
13. Kapanma/kutuya yerleşme testi

Hata Kodu Yapısı (X.Y.Z Formatı):

 Görsel 1: Rutin Test Usulü Dokümanı Örneği – 45+ Adımlık Test Algoritması ve Karar Ağacı (Temsilidir.)

Yeni Raporlama Mimarisi

Eski kaotik veri tabanı tamamen süreç mimarisine uygun olarak yeniden tasarlandı:

Yeni Tabloda Erişilebilir Veriler:

• Arıza oranları (model bazlı)
• Arıza kaynakları (hata kodu bazlı)
• Giriş/çıkış tarihleri
• Müşteri bilgileri
• Cihaz akıbet durumu

Haftalık Takip Sistemi: Hatalar ve eksik girişler ivedilikle düzeltilerek sürdürülebilir bir veri bütünlüğü korundu.

Sonuçlar ve Operasyonel Kazanımlar

Sayısal Sonuçlar

Operasyonel Kazanımlar

Problem Modeli Keşfi

Veri analizi sayesinde kritik anomaliler proaktif şekilde tespit edildi:

Bulgu: Yüksek hacimli TWS modelinde devasa sayıda faturası kesilen “Sorun Görülmedi” vakası → Anomali istatistikleriyle, raporların yetersiz kaldığı ve geçici arıza paterninin kronikleştiği saptandı → Global operasyonel politika acilen revize edildi.

İlgili Bağlantılar

 Proje Kartı: VoC Analitiği ve Kritik Kalite Kriz Yönetimi
 Proje Kartı: L1/L2 Destek Mimarisi ve Bilgi Yönetimi

Proje Künyesi

Mevcut Durum ve Kriz

Bağlam: Türkiye pazarında aktif on binlerce mobil cihaz ve günlük akışta Teknik Operasyon Merkezi’ne ulaşan binlerce karmaşık son kullanıcı talebi.

Sorun: Sıradan kırık veya çatlak vakalarının ötesinde, marka itibarını ve distribütörün finansal yapısını derinden tehdit eden sessiz bir kriz büyümekteydi:

Aksiyon ve Çözüm Mimarisi

Mimari Yaklaşım: Krizle teker teker değiştirerek mücadele etmek yerine; sorunun kök nedenini matematiksel olarak ispatlayan 3 katmanlı bir veri ve müzakere yaklaşımı kurgulandı.

Veri Sınıflandırma ve Triyaj

Operasyonel veri devasa gürültüden arındırıldı. Tüm son kullanıcı talepleri SKU bazında ayrılarak iki ana veri setine bölündü:

Dataset A (Kritik):

• Üretim hatası kaynaklı donanımsal anakart arızaları
• Montaj bazlı ekran ayrılması ve sensör kayıpları
• Ani ölüm sendromu reaksiyonları

Dataset B (Gürültü):

• Kullanıcı kaynaklı kozmetik hatalar
• Şebeke veya lojistik eksenli talepler

 Görsel 1: Veri Sınıflandırma Tablosu Örneği (Temsilidir.)

Örüntü Tanıma ve Kök Neden Analizi

Ayrıştırılan Kritik Veri seti üzerinde yapılan çapraz analizle:

• Belirli modellerde ekran ayrılmalarının kullanıcı hatası değil, fabrikasyon montaj kimyasalı yetersizliği olduğu açıkça kanıtlandı.
• Bir serideki kilitlenme sorunlarının belirli bir Over-The-Air (OTA) yazılım güncellemesi ile senkronize korelasyonu belirlendi.
• Arızalı cihazların seri numaraları üretim tarihleri ile eşleştirilerek kusurlu üretim partisinin tam izolasyonu yapıldı.

Model Bazlı Kritik Bulgular:

 Görsel 2: Model Bazlı Arıza Yoğunluğu – Servis raporu tablosu (Temsilidir.)

Stratejik Eskalasyon ve Finansal Kanıt

Hazırlanan operasyonel donanım analizi, c-level yönetimin ve üreticinin (Vendor) dili olan finansal metrik dokümanına dönüştürüldü. “Teknik Destek Talebi” refleksi yerine resmi bir “Ticari Risk Bildirimi” kurgulandı.

Analiz:

• Her serinin Birim İthalat Maliyeti ile Operasyonel Kar Merkezi karşılaştırıldı.
• Garanti maliyetlerinin global norm olan %2’yi majör oranda aştığı, birim karlılığın negatife geçerek sürdürülemez olduğu somutlandırıldı.
• Seri bazlı operasyonel zarar projeksiyonu (SLA) inşa edildi.

Aksiyon: Global merkeze resmi durum raporlaması ve yasal defo bildirimi iletildi

 Görsel 3: Global merkeze gönderilen durum bildirimi içeriği (Temsilidir.)

Operasyonel Kazanımlar

Operasyonel Dönüşüm:

İlgili Bağlantılar

 Proje Kartı: L1/L2 Destek Mimarisi ve Bilgi Yönetimi
 Proje Kartı: IoT Operasyon Mimarisi