Deep Learning Tutorials by Murat Karakaya Akademi

BU BALONU KİM ŞİŞİRİYOR?

noreply@blogger.com (Murat Karakaya) — Sun, 27 Sep 2026 12:32:29 +0000

YAPAY ZEKÂ · SOSYAL MEDYA · ELEŞTİREL BAKIŞ

Yapay Zekâ Balonunu Kim Şişiriyor? OpenClaw’dan Sıradaki “Büyük Devrime”

“Hayatımı değiştirdi” videoları, Mac mini tavsiyeleri, bulut sunucuları ve indirim kuponları… Peki, ilk günkü heyecandan sonra geriye ne kaldı?

🎈 Yapay zekâ alanında çok hızlı ve köklü değişiklikler oluyor. Ama bunların birçoğu da balon gibi şişiriliyor, sonra da patlıyor. Benim merak ettiğim, bu balonları kimin şişirdiği ve patladıktan sonra kimin dönüp arkasına baktığı.

📣 Özellikle YouTube veya X gibi sosyal medya ortamlarında, tek derdi çok sayıda tıklama almakmış gibi davranan sözde “yapay zekâ uzmanları” var. Yeni bir büyük dil modeli, araç, uygulama veya teknik mi çıktı? Daha ne işe yaradığını, hangi koşullarda başarılı olduğunu ve nerede zorlandığını anlamadan videolar hazır: “Her şey değişti!”, “Artık hiçbir şey eskisi gibi olmayacak!”, “Bunu kullanmayan geride kalacak!”

🤔 Bir süre sonra insan şunu sormadan edemiyor: Madem her hafta her şey değişiyor, geçen haftaki büyük devrime ne oldu?

🦞 OpenClaw: Daha adını öğrenemeden hayatımız değişmişti

OpenClaw etrafında oluşan tanıtım furyası, bu konudaki gözlemimi çok iyi anlatıyor. Clawdbot, ardından Moltbot, sonra OpenClaw… Daha aracın adını öğrenemeden bir sonraki ismine geçtik. :) Projenin kendi duyurusu da bu isim yolculuğunu anlatıyor; ilk isim değişikliğinin arkasında Anthropic’in marka konusundaki itirazı bulunuyor. [1]

Peter Steinberger’in başlattığı bu açık kaynaklı kişisel yapay zekâ asistanı, mesajlaşma uygulamaları üzerinden çeşitli işler yaptırma fikriyle dikkat çekti. Bu fikir elbette ilgi çekici. Ama sosyal medyada karşılaştığım anlatı, bir aracın olanaklarını tanıtmaktan çok daha ileri gidiyordu: Hayatlarını değiştirmişti, işlerini devralmıştı, hepimizin bir an önce bu devrime katılması gerekiyordu.

Steinberger’in yapay zekâ kodlama ajanlarıyla çalışma biçimi de bu hikâyenin bir parçası oldu. “Okumadığım kodu yayımlıyorum” açıklaması dikkat çekiciydi. Ancak röportajında planlama, mimari kararlar, testler ve geri bildirim süreçlerini de anlatıyordu. Bu ayrıntılar kaybolunca geriye kolay tüketilen bir masal kalıyor: Bir kişi yapay zekâya bir şey söyledi ve ortaya dünyayı değiştiren bir yazılım çıktı. Oysa aynı röportaj, deneyimli bir geliştiricinin mühendislik tercihlerini de içeriyor. [2]

🛒 “Büyük devrim”in hemen altında satın alma bağlantısı

İş yalnızca aracı övmekle de kalmadı. İzlediğim içeriklerde dönüp dolaşıp iki öneri karşıma çıkıyordu: Mac mini alın veya bulutta bir sunucu kiralayıp orada çalıştırın. OpenClaw çevresindeki Mac mini heyecanı dönemin teknoloji haberlerine de yansıdı. Bulut sağlayıcıları ise OpenClaw için hazır kurulum seçenekleri sundu. [3] [4]

Bazı tanıtımlarda sunucu kiralama önerisinin yanında içerik üreticisine ait bağlantı ve indirim kuponu da vardı. Örneğin “RIP Mac Mini!” başlıklı bir OpenClaw videosunun açıklamasında, Hostinger VPS için içerik üreticisinin adıyla bir kupon kodu sunuluyordu. Yani teknik bir öneriyle ticari yönlendirme aynı içerikte buluşuyordu. [5]

Bir içerik üreticisinin sponsorluk alması veya indirim kodu paylaşması tek başına sorun değil. Benim itirazım, satın alma tavsiyesinin dayanağının belirsiz kalmasına. İzleyiciye ne kadar süre denenmiş bir çözüm öneriliyor? Hangi ihtiyacı karşılıyor? Yeni donanım veya abonelik gerçekten gerekli mi? Denemenin sonunda beklenen fayda çıkmazsa bu da aynı açıklıkla anlatılıyor mu?

💬 “Bu araç hayatınızı değiştirecek!” diyen birinin, birkaç ay sonra “Peki, benim hayatımda neyi değiştirdi?” sorusuna da cevap vermesini beklemek fazla mı?

📊 Google Trends grafiği, seçilen dönem ve bölge içindeki göreli arama ilgisini gösterir; kullanıcı sayısını veya toplam video sayısını ölçmez. Buradaki gözlem, ilginin zirveye göre belirgin biçimde gerilemesidir.

📉 Patlayan şey, şişirilen ilgi balonu

OpenClaw için baktığım Google Trends ekranında, dünya genelinde son bir yıldaki arama ilgisi önce hızla yükseliyor, ardından zirvesinin oldukça altına geriliyor. İlk günlerdeki tanıtım furyasını düşündüğümde bu görüntü bana çok tanıdık geliyor: Büyük bir heyecan, peş peşe içerikler ve ardından giderek azalan görünürlük.

Benim “balon” dediğim tam da etrafında oluşturulan bu ilgi ve beklenti. Aracın yeni sürümü çıkabilir, geliştirilmesi sürebilir, birileri ondan fayda sağlamaya devam edebilir. Ama onu her gün büyük bir devrim diye anlatanların ilgisi nereye gitti? Asıl merak ettiğim bu.

Yeni gelişmeleri, yeni kullanım senaryolarını, uzun süreli deneyimlerini neden aynı heyecanla görmüyoruz? O gün “Artık bütün işlerimi buna yaptırıyorum” diyenlerin bugün hangi işlerini ona yaptırdığını öğrenmek isterdim. Benim karşıma, ilk günlerdeki tanıtım yoğunluğuyla kıyaslanabilecek bir deneyim paylaşımı çıkmıyor.

🔁 Her “devrim”de aynı içerik döngüsü

Farklı araçlarda tekrar tekrar karşılaştığım bir yayın alışkanlığı var. Ürün değişiyor, video başlığı ve şaşkın yüz ifadesi çoğu zaman aynı kalıyor.

01 · Duyuru gelir

Yeni bir model veya araç tanıtılır. Üreticinin seçtiği etkileyici örnekler ve performans iddiaları dolaşıma girer.

02 · İddia büyür

“Belirli bir işte yararlı olabilir” cümlesi, birkaç paylaşım sonra “Bütün işleri değiştirecek” başlığına dönüşür.

03 · Aynı anlatı çoğalır

Aynı demo, aynı örnek, aynı iddia farklı kanallarda karşımıza çıkar. Tek bir kaynaktan yayılan heyecan, çok sayıda bağımsız doğrulama varmış gibi görünebilir.

04 · Satın alma önerisi gelir

Donanım, abonelik, sunucu, kurs veya kupon bağlantısı anlatıya eklenir. İzleyici, ihtiyacını değerlendirmeden harekete geçmeye teşvik edilir.

05 · Sıradaki devrime geçilir

Önceki iddiaların sonucunu anlatmak için pek zaman kalmaz. Çünkü tanıtılmayı bekleyen yeni bir “her şeyi değiştiren” araç vardır.

🦜 Papağan gibi tekrar etmek, uzmanlık mı?

Bir başka kanalda veya mecrada yayımlanan içeriği düşünmeden, incelemeden, denemeden ve yorumlamadan aktarmak kolay. Özellikle de hazır bir demo ve etkileyici bir başlık varsa. Ama aynı iddiayı Türkçeye çevirmek, ona birkaç şaşkınlık ifadesi eklemek ve yayımlamak ne kadar uzmanlık sayılır?

Uzmanlık iddiası, bilginin üzerine bir şey koymayı gerektirir. Hangi koşullarda işe yarıyor? Hangi durumda başarısız oluyor? Karşılaştırılan yöntemler aynı işi mi yapıyor? Gösterilen sonuç, seçilmiş tek bir başarılı örnek mi, yoksa tekrarlanabilen bir performans mı? Bu sorulara zaman ayırmadan yapılan tanıtım, izleyicinin karar vermesine ne kadar yardımcı olabilir?

Her içerik üreticisinden akademik makale beklemiyorum. Ama “İlk kez deniyorum”, “Bu üreticinin iddiası”, “Bunu kendi işimde henüz test etmedim” demek zor olmamalı. Denemediğini denemiş gibi, anlamadığını çözmüş gibi ve sınırlı bir örneği herkes için geçerliymiş gibi sunmamak da işin bir parçası.

🧪 İlk günkü demo yerine üçüncü ayın bilançosu

Bence en değerli içeriklerden biri, bir aracın birkaç ay sonra yeniden değerlendirilmesi olurdu. Kurulum tamamlandıktan, ilk heyecan geçtikten ve günlük işlerin sıradan sorunları başladıktan sonra ne kaldı?

Tanıtımda duyduğumuz	Devamında öğrenmek istediğimiz
“Hayatımı değiştirdi.”	Hangi işi, ne sıklıkla ve ne kadar süredir yapıyor?
“Bana saatler kazandırıyor.”	Kurulum, bakım ve hata düzeltme süreleri hesaba katıldığında ne kadar zaman kalıyor?
“Çok ucuz çalışıyor.”	Model kullanımı, sunucu, abonelik ve donanım dâhil toplam maliyet ne?
“Her şeyi kendi yapıyor.”	Kaç işte insan kontrolü veya müdahalesi gerekiyor?
“Mutlaka almalısınız.”	Kim için gerekli? Kim mevcut araçlarıyla aynı ihtiyacı karşılayabilir?

Hatta bazen en faydalı devam videosu şu olabilir: “Size önermiştim ama ben kullanmayı bıraktım. İşte nedenleri.” Böyle bir cümle, bana göre içerik üreticisinin güvenilirliğini azaltmaz. Tam tersine, deneyimini izlenme kaygısından daha fazla önemsediğini gösterir.

💸 Balon patlayınca fatura kimde kalıyor?

Bir sonraki videoya geçmek kolay. Ama izleyicinin aldığı cihaz, başlattığı abonelik, kiraladığı sunucu ve kurulum için harcadığı zaman yerinde duruyor. Bunların her biri, karşılığında işe yarayan bir sonuç alınıyorsa anlamlı olabilir. Sorun, ihtiyacın önüne “Bu devrimi kaçırmamalıyım” duygusunun geçmesi.

Bir başka maliyet de beklentiler. Her yeni araca olağanüstü yetenekler atfedildiğinde, gerçek kullanımda yaşanan sıradan bir başarısızlık bile büyük hayal kırıklığına dönüşebiliyor. Böylece işe yarayabilecek bir teknolojiyi anlamak için gerekli sabır da kayboluyor. Önce gereğinden fazla yüceltiyor, sonra beklediğimiz mucize gelmeyince hızla başka bir araca koşuyoruz.

Yapay zekâ balonu için çok şey söylenebilir. Ama bence bu balonu şişiren en önemli etkenlerden biri, bir başka mecradaki heyecanı sorgulamadan çoğaltan ve önceki tavsiyelerinin sonucunu takip etmeyen “Yapay Zekâ Uzmanları”.

🎭 Sıradaki başlık: “LLM’leri bitiren Jev”

Şimdi de Jev konuşuluyor. TypeSafe’ın resmî belgelerinde Jev; yazılımlar için yapılandırılmış kararlar üreten, seçenekler arasından seçim yapabilen ve olasılıklar döndüren bir model olarak tanımlanıyor. Aynı belgeler, onun metin üretmediğini, kod yazmadığını ve sohbet etmediğini açıkça belirtiyor. [6]

Bu yaklaşım belirli uygulamalar için yararlı olabilir ve incelenmeyi hak eder. Ama buradan “LLM’ler bitti” sonucuna nasıl sıçrıyoruz? Belirli bir karar görevinde hız veya maliyet avantajı göstermek ile büyük dil modellerinin bütün kullanım alanlarını devralmak arasında epey mesafe var.

Yeni bir tekniğin değerini anlamak için önce hangi problemi çözdüğüne bakmak gerekiyor. Daha ilk gün onu bütün bir alanın sonu ilan ettiğimizde, teknik tartışma yine tanıtım gürültüsünün içinde kayboluyor.

🙂 Günahları boyunlarına! Ama izleyenlerin zamanı, parası ve beklentileri de bu balonlarla birlikte uçup gidiyor.

💬 Siz hâlâ OpenClaw kullanıyor musunuz? Kullanıyorsanız hangi işinizde fayda sağlıyor? Bıraktıysanız neden bıraktınız? İlk günkü heyecandan sonra kalan gerçek deneyimleri merak ediyorum.

🎈 Neyse, OpenClaw’ı bırakalım; sıradaki “büyük devrime” geçelim… “LLM’leri bitiren” Jev’i duydunuz mu? :)

🏷️ #YapayZeka #OpenClaw #Jev #ÜretkenYapayZeka #YapayZekaBalonu #EleştirelDüşünme #SosyalMedya #Teknoloji #MuratKarakayaAkademi

SOMEBODY STOP US: Who Will Control Artificial Intelligence?

noreply@blogger.com (Murat Karakaya) — Sat, 26 Sep 2026 20:42:16 +0000

SOMEBODY STOP US: Who Will Control Artificial Intelligence?

Is artificial intelligence really slipping out of control, or are we moving toward a different kind of danger: a future in which only a handful of governments and technology giants are able to develop the most advanced AI systems?

For me, the central question is no longer simply, “How dangerous could artificial intelligence become?”

The more important question is:
“Who will control artificial intelligence, and could that control mechanism eventually turn into a monopoly that decides who is allowed to develop AI?”

2023: The First Serious Alarm Bells

Today’s debate is not entirely new. The year 2023 marked an important turning point in discussions about the future of artificial intelligence.

Geoffrey Hinton, one of the pioneers of modern AI, left Google in 2023 and began speaking more openly about the risks of artificial intelligence. He warned that AI systems were developing much faster than he had expected and that increasingly capable systems could create serious risks in the future.

In the same year, an open letter published by the Future of Life Institute made an even more extraordinary proposal.

Among its signatories were Elon Musk, Yoshua Bengio, Steve Wozniak and many researchers and technology leaders.

The letter called for at least a six-month pause in the training of AI systems more powerful than GPT-4.

At the time, many people considered the proposal unnecessarily dramatic.

The dominant logic of the technology industry was exactly the opposite: build larger models, use more computing power, collect more data, and push performance further.

Three years later, however, the picture looks quite different.

2026: This Time, the AI Companies Themselves Are Sounding the Alarm

Today, concerns about AI safety are no longer being raised only by academics, activists or technology critics.

Some of the companies leading the AI race are themselves calling for stronger safety and governance mechanisms.

OpenAI has supported mandatory, capability-based national AI safety rules. Anthropic has argued that a technology developing as rapidly and affecting society as broadly as artificial intelligence should not be governed by industry alone, and that governments also need enforceable rules. Google DeepMind, through its Frontier Safety Framework, has established critical capability thresholds for areas including cybersecurity, biological risk, autonomy, manipulation and loss of control.

In other words, the debate is no longer purely theoretical.

The companies developing the most capable AI systems are themselves evaluating scenarios in which future models could enable powerful cyberattacks, biological threats, large-scale manipulation or serious control problems.

And the concern is no longer limited to malicious humans using AI.

Increasing attention is also being paid to highly autonomous systems that may pursue unintended objectives, circumvent human supervision or behave in unexpected ways.

Therefore, it would be a mistake to dismiss the entire AI safety debate as manufactured fear. There are real technical and societal risks that deserve serious attention.

But Another Race Is Taking Place at the Same Time

This is where the second part of the problem begins.

Artificial intelligence is no longer merely a scientific or commercial technology.

It has become a strategic technology with implications for economic power, cybersecurity, defense, intelligence, scientific research and geopolitical influence.

This leads to another powerful argument, particularly in the United States:

“If we slow down, there is no guarantee that our competitors will slow down with us.”

The fact that the U.S. AI Action Plan prominently frames the issue in terms of “Winning the AI Race” illustrates how central this logic has become.

The plan emphasizes accelerating innovation, expanding AI infrastructure and maintaining American leadership in artificial intelligence.

Particularly in the context of competition with China, AI policy is increasingly beginning to resemble national security policy rather than conventional innovation policy.

This creates a remarkably difficult equation:

On one side:
More capable AI models could create serious risks. Testing, oversight, safety standards and, in some cases, restrictions may be necessary.

On the other side:
If one country or company slows down, there is no guarantee that its competitors will do the same.

My concern begins precisely where these two arguments intersect.

Could Safety Regulation Become a Barrier to Entry?

I also believe that artificial intelligence needs meaningful control mechanisms.

But I strongly disagree with the assumption that “AI needs control” must automatically lead to the conclusion that control should rest in the hands of a few large governments and a few major corporations.

Regulation creates a very important structural problem:

A safety requirement that is relatively easy for a trillion-dollar company to satisfy can become an impossible barrier for a startup, university laboratory or independent research group.

Imagine that developing a frontier model eventually requires extremely expensive licenses, mandatory certification, multimillion-dollar safety infrastructure, audits that can only be conducted by a small number of approved organizations, or special government authorization.

On paper, the rules might apply equally to everyone.

In practice, however, only a very small number of organizations might still be able to develop advanced AI.

Would such regulation reduce competition?
Would it make it harder for new companies to emerge?
Would it restrict frontier AI research at universities?
Would it ultimately strengthen the position of the companies already dominating the field?

I believe these questions deserve much more attention.

Why the Nuclear Technology Analogy Keeps Appearing

Artificial intelligence is frequently compared with nuclear technology.

The analogy has obvious limitations.

An AI model is not a nuclear reactor. Software can be copied, modified and deployed in many different parts of the world.

Yet when we look specifically at frontier AI, one important similarity is becoming increasingly difficult to ignore.

Developing the most advanced systems requires rapidly increasing amounts of computing power, energy, data-center infrastructure, advanced semiconductors, highly specialized human capital and enormous financial resources.

If heavy regulatory requirements are added on top of these existing barriers, frontier AI development may naturally become concentrated in the hands of fewer and fewer actors.

And that creates an uncomfortable relationship between safety regulation and the centralization of technological power.

Why Open-Weight AI Is at the Center of This Debate

One of the most important battlegrounds in this discussion will be open-source AI and, more precisely, open-weight models whose model weights are available for others to access and use.

Open models offer important advantages.

Universities can conduct independent research. Startups can develop products without becoming completely dependent on large API providers. Organizations can run models on their own infrastructure without sending sensitive data to third parties. Countries can develop systems tailored to their own languages, cultures and strategic needs.

At the same time, openness can also make it easier to remove safety mechanisms or modify highly capable models for malicious purposes.

Therefore, there is no simple answer to the question of whether AI should be open or closed.

But one distinction is essential.

Discussing the risks of open models is one thing.

Using those risks as a justification for creating an AI ecosystem in which everyone becomes dependent on a handful of closed platforms is something entirely different.

But There Is Also Important Counter-Evidence

If we want to evaluate this issue seriously, we should not only look for evidence that supports our concerns.

We should also look for evidence that challenges them.

At present, there is no clear evidence that the major AI companies are collectively pursuing a strategy to eliminate open AI.

Anthropic CEO Dario Amodei has stated that his company does not advocate banning open-weight models and has described open models without dangerous capabilities as a public good.

More importantly, the current U.S. AI Action Plan explicitly includes policies aimed at supporting open-source and open-weight AI.

The plan recognizes the value of open models for startups, academic research, organizations working with sensitive data, and the broader international influence of the U.S. technology ecosystem.

Therefore, it would not be justified to claim that there is already a proven plan to shut down open-source AI.

My concern is different.

We might reach the same outcome even without any secret plan.

Poorly designed incentives, excessively expensive safety obligations, concentration of computing power and national-security concerns could gradually create a system in which only a small number of actors are capable of developing frontier AI — even if nobody originally intended to create such a monopoly.

The Next Stage: AI Sovereignty

For me, this issue extends far beyond competition between companies.

The larger question concerns countries.

In the future, having strong AI researchers may not be enough to develop the most capable AI systems.

Countries may also need access to advanced GPUs, massive data centers, energy infrastructure, leading-edge semiconductor technologies, significant capital and international supply chains.

If international licensing systems, export controls or authorization mechanisms for frontier AI are added to this structure, technological sovereignty will become an even more important issue.

At that point, we may have to ask:

If a country needs another country's permission to develop one of the most important general-purpose technologies of the future, can it really be considered technologically independent?

This question will become increasingly strategic for every country that wants to be not merely a user of artificial intelligence, but also a producer of it — including Türkiye.

So Is the Solution “No Regulation at All”?

No.

I believe both extremes in the AI debate are problematic.

The first extreme is to allow technology to advance without meaningful oversight and simply expect the market to solve serious safety problems.

The second extreme is to use safety concerns to create a system in which the ability to develop advanced AI is effectively controlled by a handful of companies and governments.

What we need is a governance model somewhere outside these two extremes.

Regulation should be based on measurable capabilities and risks rather than company names or model size alone.

Audit criteria should be transparent.

Universities and independent researchers should retain the ability to conduct meaningful AI safety research.

Compliance costs should not automatically push startups and smaller research organizations out of the field.

Not every open model should be treated as belonging to the same risk category.

A small language model and a frontier system capable of advanced biological design or sophisticated cyber operations should not necessarily be governed by identical rules.

And perhaps most importantly:

The rules governing the future of artificial intelligence should not be written only by the AI companies themselves.

When the companies being regulated also become the primary architects of the regulation, a natural conflict of interest may emerge.

The Real Issue May Be Bigger Than Safety

The developments of the past three years have made one thing increasingly clear to me.

AI safety is a real issue and deserves serious attention.

But from now on, it will not be enough to ask whether AI models themselves are safe.

We also need to ask how economic, technological and political power over artificial intelligence is distributed.

Because an AI ecosystem that is safe but completely controlled by a very small number of actors may not be an ideal outcome for humanity either.

I believe one of the most important technology-policy debates of the coming years will therefore be:

How should we control artificial intelligence?

And more importantly:
Who will control those who control AI?

My concern, therefore, is not that we should avoid controlling artificial intelligence.

Quite the opposite.

We should build serious, scientific, transparent and democratically accountable mechanisms for governing advanced AI.

But while trying to make AI safer, we should be careful not to turn one of the most powerful technologies in history into the permanent privilege of a few governments and a few giant corporations.

Because one day, the biggest problem may not be that artificial intelligence has escaped our control.

It may be that control over artificial intelligence has become far too concentrated.

What do you think?
Do frontier AI systems require stronger global oversight? Or could the mechanisms created to ensure safety eventually produce an even greater risk by concentrating technological power in the hands of a few countries and corporations?

#ArtificialIntelligence #AISafety #AIGovernance #OpenSourceAI #OpenWeights #FrontierAI #AGI #TechPolicy #AIRegulation #AISovereignty #OpenAI #Anthropic #DeepMind #MuratKarakayaAkademi

BİRİ BİZİ DURDURSUN: Yapay Zekâyı Kim Kontrol Edecek?

noreply@blogger.com (Murat Karakaya) — Sat, 26 Sep 2026 20:40:18 +0000

BİRİ BİZİ DURDURSUN: Yapay Zekâyı Kim Kontrol Edecek?

Yapay zekâ gerçekten kontrolden mi çıkıyor, yoksa “güvenlik” tartışmasının sonunda çok daha farklı bir tehlikeyle mi karşılaşacağız: Yapay zekâyı geliştirme gücünün birkaç devlet ve birkaç büyük şirketin elinde toplanması?

Benim için asıl soru artık yalnızca “Yapay zekâ ne kadar tehlikeli olabilir?” değil.

Asıl soru şu:
“Yapay zekâyı kim kontrol edecek ve bu kontrol mekanizması bir süre sonra kimin yapay zekâ geliştirebileceğine karar veren bir tekele dönüşecek mi?”

2023: İlk ciddi alarm zilleri

Bugünkü tartışma aslında yeni değil. 2023 yılı, yapay zekânın geleceği konusunda önemli bir kırılma noktasıydı.

Yapay zekânın öncülerinden Geoffrey Hinton, 2023'te Google'dan ayrıldıktan sonra yapay zekânın beklediğinden çok daha hızlı ilerlediğini ve bu sistemlerin gelecekte ciddi riskler yaratabileceğini açık biçimde dile getirmeye başladı.

Aynı yıl Future of Life Institute tarafından yayımlanan ve Elon Musk, Yoshua Bengio, Steve Wozniak gibi isimlerin de imzaladığı açık mektup çok daha sıra dışı bir çağrı yaptı:

GPT-4'ten daha güçlü yapay zekâ sistemlerinin eğitiminin en az altı ay süreyle durdurulması.

O gün bu çağrı bazılarına fazlasıyla dramatik gelmişti. Çünkü teknoloji dünyasının genel refleksi tam tersiydi: Daha büyük modeller, daha fazla hesaplama gücü, daha fazla veri ve daha yüksek performans.

Fakat aradan üç yıl geçtiğinde ilginç bir tablo ortaya çıktı.

2026: Bu kez alarmı yapay zekâ şirketlerinin kendileri çalıyor

Bugün artık yalnızca akademisyenler veya teknoloji eleştirmenleri değil, yapay zekâ yarışının tam merkezindeki şirketler de çok daha güçlü güvenlik ve yönetişim mekanizmalarından söz ediyor.

OpenAI, 2026 yılında ulusal düzeyde zorunlu ve yetenek-temelli yapay zekâ güvenliği düzenlemelerini desteklediğini açıkladı. Anthropic, yapay zekâ gibi hızla ilerleyen ve çok geniş etki alanına sahip bir teknolojinin yalnızca sektör tarafından yönetilemeyeceğini, devletlerin de bağlayıcı kurallar koyması gerektiğini savunuyor. Google DeepMind ise Frontier Safety Framework kapsamında biyogüvenlik, siber güvenlik, otonomi, manipülasyon ve kontrol kaybı gibi alanlarda kritik yetenek eşikleri tanımlıyor.

Yani artık tartışma teorik olmaktan çıkıyor.

Şirketler kendi geliştirdikleri sistemlerin gelecekte çok ciddi siber saldırı, biyolojik tehdit, kitlesel manipülasyon veya kontrol problemi yaratabilecek yeteneklere ulaşabileceğini bizzat kendi güvenlik dokümanlarında değerlendiriyor.

Üstelik mesele yalnızca kötü niyetli insanların yapay zekâyı kullanması da değil. Giderek daha fazla araştırma, yüksek derecede otonom sistemlerin hedeflerinden sapması, insan denetimini atlatması veya beklenmeyen davranışlar geliştirmesi gibi senaryoları da inceliyor.

Dolayısıyla “yapay zekâ güvenliği” meselesini tamamen uydurulmuş bir korku olarak görmek doğru olmaz. Ortada gerçekten üzerinde çalışılması gereken teknik ve toplumsal riskler var.

Fakat aynı anda başka bir yarış sürüyor

Sorunun ikinci tarafı burada başlıyor.

Yapay zekâ artık yalnızca bilimsel veya ticari bir teknoloji değil. Aynı zamanda ekonomik güç, siber güvenlik, savunma, istihbarat, bilimsel araştırma ve jeopolitik üstünlük açısından stratejik bir teknoloji.

Bu nedenle ABD'nin yaklaşımında başka bir güçlü argüman daha bulunuyor:

“Biz yavaşlarsak, rakiplerimiz yavaşlamak zorunda değil.”

ABD'nin resmi AI Action Plan'ının adının bile “Winning the AI Race” olması bu yaklaşımın ne kadar merkezi olduğunu gösteriyor. Plan; inovasyonun hızlandırılmasını, yapay zekâ altyapısının büyütülmesini ve ABD'nin küresel yapay zekâ liderliğinin korunmasını temel stratejik hedefler arasında görüyor.

Özellikle Çin ile rekabet söz konusu olduğunda teknoloji politikası giderek klasik bir inovasyon politikasından çok ulusal güvenlik politikasına benzemeye başlıyor.

Böylece ortaya son derece zor bir denklem çıkıyor:

Bir tarafta:
Daha güçlü modeller ciddi riskler yaratabilir. Denetim, test, güvenlik standartları ve bazı durumlarda kısıtlamalar gerekebilir.

Diğer tarafta:
Bir ülke veya şirket yavaşladığında rakiplerinin de yavaşlayacağının hiçbir garantisi yok.

İşte benim kaygım bu iki argümanın kesiştiği noktada başlıyor.

Güvenlik mekanizması zamanla bir giriş bariyerine dönüşebilir mi?

Yapay zekâ için bir kontrol mekanizmasına ihtiyaç olduğunu ben de düşünüyorum.

Ancak “kontrol gerekli” önermesinden otomatik olarak “kontrol birkaç büyük devletin ve birkaç büyük şirketin elinde olmalı” sonucunun çıkmasını son derece tehlikeli buluyorum.

Çünkü düzenleme tasarımında çok kritik bir sorun vardır:

Büyük şirketlerin kolayca yerine getirebildiği bir güvenlik zorunluluğu, küçük şirketler, üniversiteler ve bağımsız araştırmacılar için aşılması imkânsız bir maliyet oluşturabilir.

Örneğin bir frontier model geliştirmek için çok yüksek lisans ücretleri, zorunlu sertifikasyon süreçleri, milyonlarca dolarlık güvenlik altyapısı, yalnızca belirli kuruluşların gerçekleştirebildiği denetimler veya devlet tarafından verilen özel izinler gerekli hale gelirse, kâğıt üzerinde herkes için geçerli olan bir güvenlik rejimi pratikte yalnızca birkaç kuruluşun faaliyet gösterebildiği bir pazara dönüşebilir.

Bu durumda düzenleme rekabeti azaltmaz mı?
Yeni şirketlerin ortaya çıkmasını zorlaştırmaz mı?
Üniversitelerin ve bağımsız araştırmacıların frontier AI çalışmalarını sınırlandırmaz mı?
Sonuçta mevcut büyük oyuncuların konumunu daha da güçlendirmez mi?

İşte üzerinde durmamız gereken asıl meselelerden biri bence bu.

Nükleer teknoloji benzetmesi neden akla geliyor?

Yapay zekâ tartışmalarında nükleer teknoloji benzetmesi sık sık karşımıza çıkıyor.

Bu benzetmenin sınırları var. Yapay zekâ bir nükleer reaktör değil. Bir yazılım modeli kopyalanabilir, dünyanın farklı yerlerinde çalıştırılabilir ve çok daha geniş bir geliştirici topluluğu tarafından değiştirilebilir.

Fakat frontier AI açısından önemli bir benzerlik giderek belirginleşiyor:

En ileri sistemleri geliştirebilmek için gereken hesaplama gücü, enerji, veri merkezleri, gelişmiş yarı iletkenler, uzman insan kaynağı ve sermaye miktarı hızla büyüyor.

Buna bir de ağır düzenleyici yük eklenirse, frontier AI geliştirme kapasitesi doğal olarak giderek daha az sayıda aktörün elinde toplanabilir.

Ve tam burada güvenlik için oluşturulan sistem ile teknolojik gücün merkezileşmesi arasında rahatsız edici bir ilişki ortaya çıkabilir.

Açık ağırlıklı yapay zekâ neden bu tartışmanın merkezinde?

Bu tartışmanın en kritik cephelerinden biri açık kaynak ve özellikle open-weight, yani model ağırlıkları erişilebilir yapay zekâ modelleri olacak.

Açık modellerin çok önemli avantajları var.

Üniversiteler araştırma yapabiliyor. Küçük şirketler dev API sağlayıcılarına tamamen bağımlı olmadan ürün geliştirebiliyor. Kurumlar hassas verilerini üçüncü taraf sistemlerine göndermeden kendi altyapılarında model çalıştırabiliyor. Ülkeler kendi dilleri, kültürleri ve ihtiyaçları için modeller geliştirebiliyor.

Diğer taraftan aynı açıklık, çok yetenekli bir model söz konusu olduğunda bazı güvenlik mekanizmalarının kaldırılmasını veya modelin kötü niyetli amaçlarla değiştirilmesini de kolaylaştırabilir.

Dolayısıyla “açık mı kapalı mı?” sorusunun basit bir cevabı yok.

Fakat burada önemli bir ayrım yapmalıyız:

Açık modellerin risklerinin tartışılması başka bir şeydir.

Bu riskler gerekçe gösterilerek açık model geliştirme ekosisteminin tamamının birkaç kapalı platforma bağımlı hale getirilmesi başka bir şeydir.

Ama mevcut tabloya bakınca önemli bir karşı kanıt da var

Burada kendi kaygımızı doğrulayacak kanıtları aramak kadar, onu yanlışlayabilecek kanıtlara da bakmak gerekiyor.

Bugünkü veriler büyük yapay zekâ şirketlerinin ortaklaşa “açık yapay zekâyı ortadan kaldıralım” şeklinde bir politika yürüttüğünü göstermiyor.

Örneğin Anthropic CEO'su Dario Amodei 2026'da şirketinin açık ağırlıklı modellerin yasaklanmasını savunmadığını açıkça belirtti ve tehlikeli yeteneklere sahip olmayan açık modelleri bir kamu yararı olarak tanımladı.

Daha da önemlisi, ABD'nin mevcut AI Action Plan'ı da açık kaynak ve açık ağırlıklı modelleri destekleyen ayrı bir politika bölümü içeriyor. Belgede açık modellerin startup'lar, akademik araştırma, hassas verilerle çalışan kurumlar ve ABD'nin teknolojik etkisi açısından değerli olduğu açık biçimde ifade ediliyor.

Bu nedenle bugün itibarıyla “plan çoktan yapılmış, açık kaynak kapatılacak” demek için elimizde yeterli kanıt yok.

Benim endişem biraz farklı.

Böyle bir sonuca ulaşmak için gizli bir planın var olması bile gerekmeyebilir.

Yanlış tasarlanmış teşvikler, aşırı pahalı güvenlik yükümlülükleri, hesaplama gücünün birkaç şirkette yoğunlaşması ve ulusal güvenlik kaygıları; kimse baştan böyle bir tekel tasarlamasa bile bizi fiilen aynı noktaya götürebilir.

Bir sonraki aşama: Yapay zekâ egemenliği

Benim için mesele yalnızca şirket rekabeti de değil.

Daha büyük soru ülkeler açısından ortaya çıkıyor.

Gelecekte en güçlü yapay zekâ sistemlerini geliştirebilmek için yalnızca model geliştirme bilgisine sahip olmak yetmeyebilir.

Gelişmiş GPU'lara, dev veri merkezlerine, enerji altyapısına, ileri yarı iletken teknolojilerine, büyük miktarda sermayeye ve uluslararası tedarik zincirlerine erişim gerekecek.

Bunların üzerine uluslararası lisanslama, ihracat kontrolü veya frontier AI geliştirme izinleri gibi mekanizmalar eklendiğinde teknoloji egemenliği sorusu daha da önemli hale gelebilir.

O zaman şu soruyu sormak zorunda kalabiliriz:

Bir ülke geleceğin en önemli genel amaçlı teknolojilerinden birini geliştirebilmek için başka bir ülkenin iznine ihtiyaç duyarsa, gerçekten teknolojik olarak bağımsız sayılabilir mi?

Bu soru Türkiye dahil olmak üzere yapay zekâda yalnızca kullanıcı değil üretici olmak isteyen bütün ülkeler için giderek daha stratejik hale gelecektir.

O halde çözüm “hiç düzenleme olmasın” mı?

Hayır.

Bence yapay zekâ tartışmasında iki uç yaklaşım da problemli.

Birinci uç, teknolojinin kendi kendine ilerlemesine izin verip ciddi riskleri tamamen piyasanın çözmesini beklemek.

İkinci uç ise güvenlik gerekçesiyle yapay zekâ geliştirme yetkisini fiilen birkaç şirkete ve birkaç devlete bırakmak.

İhtiyacımız olan şey bu ikisinin dışında bir yönetişim modeli.

Düzenlemeler şirket isimlerine veya yalnızca model büyüklüğüne değil, ölçülebilir yetenek ve risklere dayanmalı. Denetim kriterleri şeffaf olmalı. Üniversitelerin ve bağımsız araştırmacıların güvenlik araştırması yapabilmesi korunmalı. Küçük şirketleri otomatik olarak piyasanın dışına itecek maliyetler yaratılmamalı.

Her açık model aynı risk sınıfında değerlendirilmemeli. Küçük bir dil modeli ile biyolojik tasarım veya ileri siber saldırı kapasitesi gösterebilen frontier modelin aynı kurallara tabi olması mantıklı değil.

Ve belki de en önemlisi:

Yapay zekânın geleceğini belirleyen kurallar yalnızca yapay zekâ şirketleri tarafından yazılmamalı.

Çünkü düzenlemenin öznesi olan şirketlerin aynı zamanda düzenlemenin nasıl olması gerektiğini belirleyen başlıca aktörler haline gelmesi doğal bir çıkar çatışması yaratabilir.

Asıl mesele güvenlikten daha büyük olabilir

Son üç yılda yaşanan gelişmeler bana bir şeyi açık biçimde gösteriyor:

Yapay zekânın güvenliği gerçekten konuşmamız gereken bir konu.

Ancak bundan sonra yalnızca modellerin güvenli olup olmadığını tartışmak yeterli olmayacak.

Aynı zamanda yapay zekâ üzerindeki ekonomik, teknik ve politik gücün nasıl dağıtıldığını da konuşmak zorundayız.

Çünkü güvenli fakat birkaç aktörün tamamen kontrol ettiği bir yapay zekâ ekosistemi de insanlık için ideal bir sonuç olmayabilir.

Bence önümüzdeki yılların en önemli teknoloji politikası tartışmalarından biri tam olarak bu olacak:

Yapay zekâyı nasıl kontrol edeceğiz?

Ve daha önemlisi:
Kontrol edenleri kim kontrol edecek?

Bu nedenle benim kaygım “yapay zekâyı kontrol etmeyelim” değil.

Tam tersine.

Yapay zekâ üzerinde ciddi, bilimsel, şeffaf ve demokratik denetim mekanizmaları oluşturalım.

Fakat bunu yaparken güvenliği sağlamak adına dünyanın en güçlü teknolojilerinden birini birkaç devletin ve birkaç dev şirketin kalıcı ayrıcalığı haline getirmeyelim.

Çünkü bir gün asıl problem yapay zekânın kontrolden çıkması değil, yapay zekânın kontrolünün fazlasıyla küçük bir grubun elinde toplanması olabilir.

Siz ne düşünüyorsunuz?
Frontier yapay zekâ sistemleri için daha güçlü bir küresel kontrol mekanizması mı gerekiyor? Yoksa bu mekanizmaların zamanla teknolojik gücü birkaç ülke ve birkaç şirketin elinde toplaması daha büyük bir risk mi?

#YapayZeka #ArtificialIntelligence #AISafety #AIGovernance #OpenSourceAI #OpenWeights #FrontierAI #AGI #TeknolojiPolitikası #YapayZekaGuvenligi #MuratKarakayaAkademi

The "Early Specialization" Fallacy in AI Careers: Why New Grads Should Embrace a Broad Profile

noreply@blogger.com (Murat Karakaya) — Sat, 26 Sep 2026 20:31:26 +0000

Recently, I received an email from a highly talented senior student whose portfolio I reviewed. It perfectly summarized the immense anxiety felt by almost everyone stepping into today's artificial intelligence ecosystem. She wrote:

"I want to get into the AI field. I've experimented with a lot of different things—local LLM integration, RAG (Retrieval-Augmented Generation), Edge AI projects... But when I look at my CV, I feel scattered. Should I narrow my portfolio and specialize in a single area before getting a job?"

This question is the clearest example of a fallacy inherited from traditional software engineering teachings hitting a brick wall in the "Age of AI". In the traditional world, the "T-shaped person" (deep in one area, broad in others) was the ideal. But when it comes to AI, the rules of the game change entirely.

The Illusion of "Maturity" Destroyed by Speed

Almost all the topics we lose sleep over today, wondering "should I specialize in this?" (Transformer architectures, Agentic RAG systems, vector databases, SLMs), are products of the last 5 to 6 years. More importantly, none of these technologies are fully mature yet.

Right now, the lifespan of a technique in the industry is measured in months. Yesterday, Prompt Engineering was an area of expertise; today, libraries like DSPy make it algorithmic. Yesterday, massive cloud models were essential; today, 8-billion parameter models running locally via Apple MLX or Ollama work wonders.

The morning after you declare yourself an "expert" in a framework or specific architecture, a brand new paper or open-source code is published that renders that architecture completely obsolete. In such a hyper-dynamic landscape, someone without industry experience making a decision for premature specialization is essentially cutting off the branch they are sitting on.

The True Expectation of Startups and Companies

When you enter the industry's kitchen, you see that reality is much more pragmatic. Most companies and agile startups aren't looking for laboratory perfection. They are looking for profiles that can integrate these rapidly changing new tools, models, and libraries into existing business processes without wasting time.

Therefore, employers prefer a "technology integrator"—someone who has dirtied their hands with RAG systems, tried running models on edge devices (Edge AI) when necessary, and experienced those constraints firsthand—over a "narrow specialist" who has academically deepened in a single algorithm but remains blind to the rest of the system. That broad spectrum you see as being "scattered" is actually proof of your “adaptation muscle,” which is your biggest competitive advantage.

Where Does True Depth Begin?

So, will there be no specialization at all? Of course there will be. But not through "choices" made from the outside before getting a job.

True specialization begins when you sit at the desk. You deepen when you try to build a RAG system on your company's 50 million lines of dirty corporate data and your system starts "hallucinating." You specialize in that area when you are forced into model quantization to increase inference speed. The needs of the project naturally and inevitably pull you into a deep well in a specific area. Sometimes this focus comes at the cost of staying away from other hot trends, but the depth you acquire is now a "useful" depth; not a hypothetical one.

My Advice to New Graduates

In summary; do not fear the diversity in your portfolio. Instead of becoming a disciple of a single topic in the AI field, build plenty of prototypes with different techniques. Make mistakes, see the limits. Master the breadth of the ecosystem so that tomorrow, when a problem arises at the company you work for, you have the vision to say, "It would be more effective if we solved this with that newly released agent architecture, rather than LangChain."

Let the epaulet called specialization settle on your shoulders naturally while you are wrestling with real-world problems.

What do you think?

How is this dizzying speed in the AI ecosystem affecting your career planning? Specialize in a narrow field, or become an integrator with a broad perspective? Let's discuss your ideas in the comments.

#ArtificialIntelligence #CareerStrategy #NewGrad #SoftwareDevelopment #MachineLearning #LLM #RAG #EdgeAI #TechCareer #SoftwareEngineering #FutureOfWork #MuratKarakayaAkademi

Yapay Zeka Kariyerinde "Erken Uzmanlaşma" Yanılgısı: Yeni Mezunlar Neden Dağınık Kalmalı?

noreply@blogger.com (Murat Karakaya) — Sat, 26 Sep 2026 20:29:41 +0000

Geçtiğimiz günlerde, portföyünü incelediğim çok yetenekli bir son sınıf öğrencisinden, bugünün yapay zeka ekosistemine yeni adım atan herkesin hissettiği o devasa anksiyeteyi özetleyen bir e-posta aldım. Şöyle diyordu:

"Yerel LLM entegrasyonu, RAG (Retrieval-Augmented Generation) denemeleri, Edge AI projeleri... Birçok alana dokundum ama CV’me baktığımda kendimi aşırı dağınık görüyorum. İşe girmeden önce portföyümü daraltıp tek bir alanda uzmanlaşmalı mıyım?"

Bu soru, geleneksel yazılım mühendisliği öğretilerinden miras kalan bir yanılgının, "Yapay Zeka Çağı'nda" duvara çarpmasının en net örneğidir. Geleneksel dünyada "T-tipi insan" (bir alanda çok derin, diğerlerinde yüzeysel bilgi sahibi olan) makbuldü. Ancak işler yapay zeka olunca, oyunun kuralları tamamen değişiyor.

Hızın Yıktığı "Olgunluk" İllüzyonu

Bugün uğruna "uzmanlaşsam mı?" diye uykularımızı kaçıran konuların (Transformer mimarileri, Agentic RAG sistemleri, vektör veritabanları, SLM'ler) neredeyse tamamı son 5-6 yılın ürünü. Daha da önemlisi, bu teknolojilerin hiçbiri henüz tam anlamıyla olgunlaşmış değil.

Şu an sektörde bir tekniğin ömrü aylarla ölçülüyor. Dün Prompt Engineering bir uzmanlık alanıydı; bugün DSPy gibi kütüphaneler bu işi algoritmik hale getiriyor. Dün devasa bulut modelleri şarttı; bugün Apple MLX veya Ollama ile lokalde koşan 8 milyar parametreli modeller harikalar yaratıyor.

Siz bir çerçevede (framework) veya spesifik bir mimaride "uzmanlaştığınızı" ilan ettiğiniz günün ertesi sabahı, o mimariyi tamamen çöpe atan yepyeni bir makale veya açık kaynak kod yayınlanıyor. Böyle hiper-dinamik bir zeminde, henüz sektör tecrübesi olmayan birinin erken uzmanlaşma (premature specialization) kararı alması, aslında bindiği dalı kesmesidir.

Girişimlerin ve Şirketlerin Asıl Beklentisi

Sektörün mutfağına girdiğinizde gerçeğin çok daha pragmatik olduğunu görürsünüz. Birçok şirket ve çevik girişim, laboratuvar mükemmelliği aramıyor. Onlar; hızla değişen bu yeni araçları, modelleri ve kütüphaneleri vakit kaybetmeden mevcut iş süreçlerine entegre edecek profiller arıyor.

Dolayısıyla işveren; tek bir algoritmada akademik düzeyde derinleşmiş ama sistemin geri kalanına kör kalmış bir "dar uzman" yerine, elini RAG sistemlerine de bulamış, yeri geldiğinde uç cihazda (Edge AI) model koşturmayı da denemiş, oradaki kısıtları bizzat yaşayarak görmüş bir "teknoloji entegratörünü" tercih ediyor. Sizin "dağınıklık" olarak gördüğünüz o geniş yelpaze, aslında en büyük rekabet avantajınız olan "adaptasyon kasınızın" bir kanıtı.

Gerçek Derinlik Nerede Başlar?

Peki uzmanlaşma hiç mi olmayacak? Elbette olacak. Ancak işe girmeden önce dışarıdan bakarak yapılan "seçimlerle" değil.

Gerçek bir uzmanlaşma, masaya oturduğunuzda başlar. Şirketinizin 50 milyon satırlık kirli kurumsal verisi üzerinde RAG yapmaya çalıştığınızda ve sisteminiz "halüsinasyon" görmeye başladığında derinleşirsiniz. Hızı artırmak için model kuantizasyonuna (quantization) mecbur kaldığınızda o alanda uzmanlaşırsınız. Projenin ihtiyaçları, sizi doğal ve mecburi bir şekilde spesifik bir alanda derin bir kuyuya çeker. Bazen bu odaklanma, diğer sıcak trendlerden uzak kalma pahasına olur, ancak edindiğiniz derinlik artık "işe yarar" bir derinliktir; varsayımsal değil.

Yeni Mezunlara Tavsiyem

Özetle; portföyünüzdeki çeşitlilikten korkmayın. YZ alanında tek bir konunun müridi olmak yerine, farklı tekniklerle bol bol prototip üretin. Hata yapın, sınırları görün. Ekosistemin genişliğine hakim olun ki, yarın çalıştığınız firmada bir problemle karşılaşıldığında "Bunu LangChain ile değil, şu yeni çıkan ajan mimarisiyle çözersek daha efektif olur" diyebilecek vizyonunuz olsun.

Bırakın uzmanlaşma denen o apolet, siz gerçek dünya sorunlarıyla boğuşurken omuzlarınıza kendiliğinden konsun.

Siz ne düşünüyorsunuz?

Yapay zeka ekosistemindeki bu baş döndürücü hız, kariyer planlamanızı nasıl etkiliyor? Dar bir alanda uzmanlaşmak mı, yoksa geniş bir perspektifte entegratör olmak mı? Fikirlerinizi yorumlarda tartışalım.

#YapayZeka #KariyerStratejisi #YeniMezun #YazilimGelistirme #MakineOgrenmesi #LLM #RAG #EdgeAI #TeknolojiKariyeri #YazilimMuhendisligi #GeleceginMeslekleri #MuratKarakayaAkademi

Are Closed LLMs Losing Their Lead? Open-Weight Models Are Moving Closer to the Frontier

noreply@blogger.com (Murat Karakaya) — Sat, 26 Sep 2026 20:17:15 +0000

```

Are Closed LLMs Losing Their Lead? Open-Weight Models Are Moving Closer to the Frontier

Inkling, Kimi K3, and Qwen3.8 changed the open-weight LLM landscape within just a few weeks, raising important questions about the future of the AI race.

As we entered the summer of 2026, the strongest players in the large language model race still looked very familiar: OpenAI, Anthropic, and other closed-model providers. Anthropic released Claude Fable 5 on June 9, 2026, while OpenAI made the GPT-5.6 family generally available on July 9 following a limited preview that began on June 26.

Both models were introduced with strong reasoning, coding, and agentic capabilities. Their advanced capabilities and potential security risks, particularly in cybersecurity, also brought them into broader discussions involving the U.S. government.

Then, within only a few weeks, three major developments changed the picture on the open-weight side.

🗓️ A landscape that changed within weeks

🇺🇸 July 15, 2026 — Inkling: Thinking Machines Lab released Inkling, an open-weight model with 975 billion total parameters and 41 billion active parameters per token.

🇨🇳 July 16, 2026 — Kimi K3: Moonshot AI announced Kimi K3, a 2.8-trillion-parameter model. Its full model weights were released on July 27.

🇨🇳 July 19, 2026 — Qwen3.8 preview: Alibaba introduced Qwen3.8-Max-Preview in the 2.4-trillion-parameter class. Qwen3.8-Max was formally introduced on August 3, followed by the open-weight Qwen3.8-2.4T-A95B model on August 12.

🇺🇸 Inkling: A major open-weight move from the United States

The significance of Inkling is not simply that it has 975 billion parameters. The model uses a Mixture-of-Experts architecture with around 41 billion active parameters per token and can reason across text, images, and audio.

It also supports agentic coding, tool use, and context windows of up to one million tokens.

What makes Inkling particularly interesting, in my view, is something else. While Chinese companies had become far more visible in frontier open-weight model development, this time a powerful and genuinely open-weight model came from a new U.S.-based AI laboratory.

🇨🇳 Kimi K3: Open-weight models approach the 3-trillion-parameter class

Immediately after Inkling, Moonshot AI introduced Kimi K3, pushing open-weight model scale into a new range.

The model contains 2.8 trillion parameters. Its MoE architecture includes 896 experts, while only 16 are activated for each token. This allows the total model size to become extremely large without requiring every parameter to participate in every inference step.

Kimi K3 also attracted attention for more than its size. Around the time of its release, it ranked first on Frontend Code Arena, ahead of Claude Fable 5.

That does not mean Kimi K3 is now simply “better than GPT-5.6 or Fable 5.” Closed frontier models still hold an advantage in many broad evaluations. But the fact that an open-weight model can outperform the strongest closed models in selected coding and agentic tasks is a substantial change compared with the situation only a few years ago.

🇨🇳 Qwen3.8: Alibaba also moves into trillion-scale open models

Alibaba’s Qwen3.8 move showed that these developments were not isolated events.

Qwen3.8-Max, previewed in July, reached its formal 2.4-trillion-parameter release in August. The Qwen team then released the weights of Qwen3.8-2.4T-A95B as well.

As a result, within a short period, the open-weight ecosystem saw new models at 975 billion, 2.4 trillion, and 2.8 trillion parameters.

⚖️ The real issue is not parameter count

A 2.8-trillion-parameter model is not automatically better than a 500-billion-parameter model. Training data quality, architecture, post-training, reinforcement learning, tool use, inference infrastructure, and active parameter count can matter just as much as total model size. The real shift is that open-weight models are beginning to operate in the same capability range as frontier systems.

🔓 Are open-weight models still six or seven months behind?

For several years, there was a fairly reasonable rule of thumb: the strongest capabilities first appeared in closed systems from companies such as OpenAI, Anthropic, or Google, while comparable open models followed months later.

That assumption now needs to be reconsidered.

Models such as Kimi K3 can enter the same performance region as GPT-5.6 and Claude Fable 5 on selected tasks. The Qwen family continues to improve rapidly in coding and agentic workloads. Inkling shows that a U.S.-based open-weight frontier model is also possible.

Open models have not yet surpassed closed models across every dimension. But in many areas, the delay no longer looks like “wait for the next model generation.”

To me, this is the more important change.

🇨🇳 Are Chinese companies catching up with U.S. frontier labs?

Recent developments make this question increasingly difficult to dismiss.

Chinese companies are no longer producing only smaller or cheaper alternatives. With Moonshot AI and Alibaba, we are now seeing models at true frontier scale, and some of them are being released with their weights.

This is particularly significant because Chinese companies are operating under restrictions affecting access to some of the most advanced U.S. AI chips. Despite this, they continue to scale through work on model architecture, sparsity, attention mechanisms, quantization, and distributed inference.

The competition may therefore increasingly shift from “Which company has the best model?” to “Which national ecosystem can still develop frontier models?”

🔐 Will Chinese companies eventually close their strongest models?

This may become one of the most interesting questions for the future of the open-weight ecosystem.

Chinese model developers have benefited significantly from open-weight strategies. Their models have spread quickly across the world, developer communities have formed around them, inference platforms have added support, and the companies themselves have gained global visibility.

But would a company follow the same strategy if it genuinely believed it had the most capable model in the world?

Or would it become commercially more attractive to keep the strongest model behind an API while releasing the previous generation as open weights?

The next few model generations may provide an answer.

🌍 Where are the countries outside the U.S. and China?

This may be one of the least discussed aspects of the current AI race.

Two ecosystems now stand out very clearly in frontier model development: the United States and China.

Europe has strong research institutions and important AI companies. Japan and South Korea have advanced semiconductor industries. India has a very large software and engineering talent base. Yet at the trillion-parameter frontier, the competition is increasingly concentrated in the U.S. and China.

The reason is that this race cannot be run with good researchers alone. It requires tens of thousands of accelerators, data-center infrastructure, energy, capital, training data, distributed-systems engineering, and a very large research ecosystem.

One of the strategic questions for the coming years will therefore be whether other countries attempt to build their own frontier-model infrastructure or become increasingly dependent on models developed in the U.S. and China.

❓ Five questions for the next phase

🔹 Can Chinese companies fully catch up with U.S. frontier-model companies technologically?

🔹 Will the performance gap between open-weight and closed models disappear within the next few generations?

🔹 To what extent will independent evaluations confirm the superiority suggested by selected benchmarks from companies such as OpenAI and Anthropic?

🔹 Will Chinese companies continue their open-weight strategies even for their most capable models?

🔹 Can countries outside the U.S. and China re-enter the frontier-model race?

🚀 Is a new era beginning for open-weight LLMs?

It is still too early to say that open-weight models have completely overtaken closed systems.

But something else can now be said with much more confidence: open-weight models are no longer sitting at the edge of the frontier AI race. They are moving closer to its center.

The rapid appearance of Inkling, Kimi K3, and Qwen3.8 is one of the clearest signs of this shift.

If the performance gap between open and closed models continues to narrow, the consequences will extend far beyond benchmark tables. It will affect how AI infrastructure is built, which model providers companies depend on, how countries think about AI sovereignty, and even the future of today’s API-centered business models.

What do you think? When will open-weight models catch closed models in overall performance? Or will the most capable models always remain closed?

Murat Karakaya Academy

#MuratKarakayaAkademi #ArtificialIntelligence #LLM #OpenWeights #OpenSourceAI #KimiK3 #Qwen38 #Inkling #GPT56 #ClaudeFable5 #AgenticAI #GenerativeAI

```

Kapalı LLM’lerin Saltanatı Sarsılıyor mu?

noreply@blogger.com (Murat Karakaya) — Sat, 26 Sep 2026 20:13:40 +0000

```

Kapalı LLM’lerin Saltanatı Sarsılıyor mu? Açık Ağırlıklı Modeller Frontier Seviyeye Yaklaşıyor

Inkling, Kimi K3 ve Qwen3.8 ile birkaç hafta içinde değişen açık ağırlıklı LLM dengesi, yapay zekâ yarışının geleceği hakkında önemli sorular ortaya çıkarıyor.

2026 yazına girerken büyük dil modeli yarışının en güçlü oyuncuları yine oldukça tanıdıktı: OpenAI, Anthropic ve diğer kapalı model sağlayıcıları. Anthropic 9 Haziran 2026'da Claude Fable 5'i, OpenAI ise 26 Haziran'daki sınırlı önizlemenin ardından 9 Temmuz'da GPT-5.6 ailesini genel kullanıma sundu.

Her iki model de yüksek akıl yürütme, kodlama ve ajan yetenekleriyle duyuruldu. Güvenlik riskleri ve özellikle gelişmiş siber yetenekleri nedeniyle ABD yönetimiyle yürütülen değerlendirme süreçleri de modellerin ne kadar güçlü hâle geldiği tartışmasını beraberinde getirdi.

Tam bu sırada, açık ağırlıklı LLM dünyasında birkaç hafta içinde oldukça önemli üç gelişme yaşandı.

🗓️ Birkaç haftada değişen tablo

🇺🇸 15 Temmuz 2026 — Inkling: Thinking Machines Lab, 975 milyar toplam ve 41 milyar aktif parametreye sahip açık ağırlıklı Inkling modelini yayımladı.

🇨🇳 16 Temmuz 2026 — Kimi K3: Moonshot AI, 2,8 trilyon parametreli Kimi K3'ü duyurdu. Model ağırlıkları 27 Temmuz'da kamuya açıldı.

🇨🇳 19 Temmuz 2026 — Qwen3.8 önizlemesi: Alibaba, Qwen3.8-Max-Preview ile 2,4 trilyon parametre sınıfına çıktı. Qwen3.8-Max 3 Ağustos'ta resmen tanıtıldı ve 2,4 trilyon toplam, yaklaşık 95 milyar aktif parametreli açık ağırlıklı Qwen3.8-2.4T-A95B 12 Ağustos'ta yayımlandı.

🇺🇸 Inkling: ABD'den uzun süre sonra güçlü bir açık ağırlık hamlesi

Thinking Machines Lab tarafından yayımlanan Inkling'in önemi yalnızca 975 milyar parametreye sahip olması değil. Model, her token için yaklaşık 41 milyar aktif parametre kullanan Mixture-of-Experts (MoE) mimarisiyle çalışıyor ve metin, görüntü ve ses üzerinde doğal olarak akıl yürütebiliyor.

Ayrıca ajan tabanlı kodlama, araç kullanımı ve bir milyon token'a kadar bağlam desteği sunuyor.

Bence Inkling'i asıl ilginç hâle getiren nokta ise başka: Uzun süredir açık ağırlıklı frontier model geliştirme tarafında Çinli şirketler çok daha görünürken, bu kez güçlü ve gerçekten açık ağırlıklı bir model ABD merkezli yeni bir laboratuvardan geldi.

🇨🇳 Kimi K3: Açık model ölçeği 3 trilyon parametre sınırına dayandı

Inkling'in hemen ardından Moonshot AI tarafından açıklanan Kimi K3, açık ağırlıklı modellerin ölçeği açısından yeni bir sınırı temsil etti.

Model toplam 2,8 trilyon parametreye sahip. MoE yapısında bulunan 896 uzmandan yalnızca 16'sı her token için aktif hâle geliyor. Böylece toplam model büyüklüğü olağanüstü seviyelere çıkarken, bütün parametrelerin her token için çalıştırılması gerekmiyor.

Kimi K3 yalnızca büyüklüğüyle de dikkat çekmedi. Yayınlandığı dönemde Frontend Code Arena'da Claude Fable 5'i geçerek ilk sıraya yerleşmesi özellikle ilgi çekiciydi.

Bu sonuçtan “Kimi K3 artık GPT-5.6 veya Fable 5'ten daha iyi” sonucunu çıkarmak doğru olmaz. Genel değerlendirmelerde kapalı frontier modeller hâlâ birçok alanda avantajlarını koruyor. Ancak belirli kodlama ve ajan görevlerinde açık ağırlıklı bir modelin en güçlü kapalı modelleri geçebilmesi, birkaç yıl önceki tabloyla karşılaştırıldığında oldukça önemli.

🇨🇳 Qwen3.8: Alibaba da trilyon parametre ölçeğinde açık modele geçti

Alibaba'nın Qwen3.8 hamlesi bu gelişmelerin tek seferlik olmadığını gösterdi.

Temmuz ayında önizlenen Qwen3.8-Max, Ağustos ayında 2,4 trilyon parametreli resmî sürümüne ulaştı. Ardından Qwen ekibi Qwen3.8-2.4T-A95B modelinin ağırlıklarını da yayımladı.

Böylece kısa süre içerisinde açık ağırlıklı ekosistemde 975 milyar, 2,4 trilyon ve 2,8 trilyon parametre ölçeğinde üç yeni model ortaya çıktı.

⚖️ Asıl mesele parametre sayısı değil

2,8 trilyon parametreli bir modelin 500 milyar parametreli bir modelden otomatik olarak daha iyi olduğunu söyleyemeyiz. Eğitim verisinin kalitesi, model mimarisi, post-training süreci, reinforcement learning, araç kullanımı, inference altyapısı ve aktif parametre sayısı en az toplam model büyüklüğü kadar önemli. Buradaki asıl değişim, açık ağırlıklı modellerin hem ölçek hem de yetenek açısından frontier modellerin bulunduğu bölgeye girmeye başlaması.

🔓 Açık ağırlıklı modeller hâlâ 6–7 ay geriden mi geliyor?

Birkaç yıl boyunca oldukça makul bir genelleme vardı: En güçlü yetenek önce OpenAI, Anthropic veya Google gibi kapalı model sağlayıcılarında ortaya çıkıyor; benzer seviyedeki açık modeller ise aylar sonra geliyordu.

Bugün bu varsayımın yeniden değerlendirilmesi gerekiyor.

Kimi K3 gibi modeller bazı görevlerde GPT-5.6 ve Claude Fable 5 ile aynı performans bölgesine girebiliyor. Qwen serisi kodlama ve ajan görevlerinde sürekli ilerliyor. Inkling ise ABD'den gelen açık ağırlıklı bir frontier modelin de mümkün olduğunu gösteriyor.

Açık modeller henüz kapalı modelleri bütün boyutlarda geçmiş değil. Ancak aradaki gecikme birçok alanda artık “bir sonraki nesli beklemek” seviyesinde görünmüyor.

Bana göre tartışılması gereken asıl değişim de burada.

🇨🇳 Çinli şirketler Amerikan şirketlerini yakalıyor mu?

Son gelişmeler bu soruyu giderek daha ciddi hâle getiriyor.

Çinli şirketler yalnızca daha ucuz veya daha küçük modeller üretmiyor. Moonshot AI ve Alibaba örneklerinde artık doğrudan frontier ölçeğinde modeller görüyoruz. Üstelik bunların bir bölümü model ağırlıklarıyla birlikte yayımlanıyor.

Bu durum özellikle önemli çünkü Çinli şirketler aynı zamanda ABD'nin en gelişmiş yapay zekâ çiplerine yönelik ihracat sınırlamaları altında çalışıyor. Buna rağmen model mimarisi, sparsity, attention mekanizmaları, quantization ve dağıtık inference gibi alanlardaki mühendislik çalışmalarıyla ölçek büyütmeye devam ediyorlar.

Dolayısıyla önümüzdeki dönemde yarış yalnızca “hangi şirketin en iyi modeli var?” sorusundan ibaret olmayabilir. “Hangi ülkenin yapay zekâ ekosistemi frontier model geliştirebiliyor?” sorusu da giderek daha önemli hâle geliyor.

🔐 Çinli şirketler güçlü hâle geldikçe modellerini kapatır mı?

Bence açık ağırlıklı ekosistemin geleceği açısından en ilginç sorulardan biri bu.

Çinli model geliştiricileri bugüne kadar açık ağırlık stratejisinden önemli faydalar elde etti. Modeller hızla dünya çapında kullanılmaya başladı, geliştirici toplulukları oluştu, inference sistemleri bu modellere destek ekledi ve şirketlerin küresel görünürlüğü arttı.

Ancak bir şirket gerçekten dünyanın en güçlü modeline sahip olduğuna inandığında aynı stratejiyi sürdürür mü?

Yoksa en güçlü modeli API arkasında tutup, bir önceki nesli açık ağırlıklı olarak yayımlamak daha avantajlı hâle mi gelir?

Önümüzdeki birkaç model nesli bu sorunun cevabı açısından oldukça belirleyici olacak.

🌍 Peki ABD ve Çin dışındaki ülkeler nerede?

Bu yarışın belki de en az tartışılan tarafı burada.

Bugün frontier model geliştirme yarışında iki ekosistem çok belirgin biçimde öne çıkıyor: ABD ve Çin.

Avrupa'nın güçlü araştırma kurumları ve önemli yapay zekâ şirketleri var. Japonya ve Güney Kore ileri yarı iletken teknolojilerine sahip. Hindistan büyük bir yazılım ve mühendislik insan kaynağı barındırıyor. Buna rağmen trilyon parametre ölçeğindeki frontier modellerde yarış giderek ABD ve Çin arasında yoğunlaşıyor.

Çünkü bu yarış yalnızca iyi araştırmacılarla yürümüyor. On binlerce hızlandırıcı, veri merkezi altyapısı, enerji, sermaye, eğitim verisi, dağıtık sistem mühendisliği ve çok büyük bir araştırma ekosistemi gerekiyor.

Dolayısıyla önümüzdeki dönemin stratejik sorularından biri de şu olacak: Diğer ülkeler kendi frontier model altyapılarını kurmaya çalışacak mı, yoksa ABD ve Çin tarafından geliştirilen modellere bağımlı mı kalacak?

❓ Önümüzdeki dönem için beş soru

🔹 Çinli şirketler Amerikan frontier model şirketlerini teknolojik olarak tamamen yakalayabilecek mi?

🔹 Açık ağırlıklı ve kapalı modeller arasındaki performans farkı birkaç nesil içinde tamamen ortadan kalkacak mı?

🔹 OpenAI ve Anthropic gibi şirketlerin seçilmiş benchmarklarla oluşturduğu üstünlük algısını bağımsız değerlendirmeler ne ölçüde doğrulayacak?

🔹 Çinli şirketler en güçlü modellerinde de açık ağırlık politikasını sürdürecek mi?

🔹 ABD ve Çin dışındaki ülkeler frontier model yarışına yeniden katılabilecek mi?

🚀 Açık ağırlıklı LLM dünyasında yeni bir dönem mi başlıyor?

Açık ağırlıklı modellerin kapalı modelleri tamamen geçtiğini söylemek için henüz erken.

Fakat artık başka bir şeyi söylemek mümkün: Açık ağırlıklı modeller frontier yapay zekâ yarışının kenarında değil, giderek daha fazla merkezinde yer alıyor.

Inkling, Kimi K3 ve Qwen3.8'in kısa aralıklarla ortaya çıkması bu değişimin güçlü işaretlerinden biri.

Eğer açık modeller ile kapalı modeller arasındaki performans farkı gerçekten kapanmaya devam ederse, bunun etkisi yalnızca benchmark tablolarında görülmeyecek. Yapay zekâ altyapılarının nasıl kurulacağı, şirketlerin hangi modellere bağımlı olacağı, ülkelerin yapay zekâ egemenliği ve hatta bugünkü API merkezli iş modellerinin geleceği de bundan etkilenecek.

Sizce açık ağırlıklı modeller kapalı modelleri genel performansta ne zaman yakalayacak? Yoksa en güçlü modeller her zaman kapalı sistemlerde mi kalacak?

Murat Karakaya Akademi

#MuratKarakayaAkademi #YapayZeka #LLM #OpenWeights #AcikAgirlik #OpenSourceAI #KimiK3 #Qwen38 #Inkling #GPT56 #ClaudeFable5 #AgenticAI #GenerativeAI #ArtificialIntelligence

```

ARTIFICIAL INTELLIGENCE • LLM • AGENTIC AI • 2027

noreply@blogger.com (Murat Karakaya) — Sat, 26 Sep 2026 20:07:53 +0000

ARTIFICIAL INTELLIGENCE • LLM • AGENTIC AI • 2027

Witnessing the AI Revolution: From Deep Learning to Long-Running AI Agents

Over the past 15 years, artificial intelligence has not merely produced better models. We have moved from systems that recognize images to models that converse with us, from conversational models to agents that use tools, and from there to AI systems capable of working on a problem continuously for hours or even days. So what will be the next major breakthrough in 2027?

A Question That Emerged from a Conversation

Today, while talking with a friend who is also deeply interested in artificial intelligence, our conversation naturally turned to the extraordinary pace of development in AI over the past few years.

After a while, we started recalling the technologies we had been discussing over the years: Deep Learning, RNNs, LSTMs, Transformers, large language models, multimodal models, reasoning models, RAG, function calling, agents, MCP, computer use, coding agents, and most recently, AI agents capable of working independently for extended periods of time.

When you put all of these developments side by side, the speed of change becomes much more visible.

In fact, we have not simply developed more capable AI models over the past few years. The way we use artificial intelligence itself has changed several times.

Artificial intelligence is evolving from a system that recognizes patterns into a system that talks to us, reasons about problems, uses tools, and increasingly performs complete tasks on its own.

🧠 1. Deep Learning: The Beginning of the Major Breakthrough

Artificial neural networks were certainly not new. However, for many years they could not demonstrate their full potential because of limitations in data availability, computing power, and training techniques.

In 2012, AlexNet’s success in the ImageNet competition demonstrated how powerful deep neural networks trained on GPUs could become.

The breakthrough that started in computer vision quickly spread to speech recognition, natural language processing, and many other machine learning problems.

From today’s perspective, this may seem almost ordinary, but one of the key foundations of the AI revolution we are experiencing today was established here:

Larger neural networks + more data + more computing power.

🔁 2. RNNs, LSTMs, and Sequence-to-Sequence Models

While CNN architectures achieved remarkable success in image processing, natural language presented a different challenge: language is sequential.

RNNs, and particularly LSTMs, made it possible to retain information from previous steps and process sentences, conversations, and time-series data more effectively.

Then came sequence-to-sequence, or seq2seq, architectures. They enabled a model to receive one sequence and generate another sequence as output. Machine translation became one of the most important applications of this idea.

Today, we consider it completely natural to give a model a piece of text and receive another piece of generated text in return. Yet encoder-decoder and seq2seq architectures were important milestones on the road toward modern generative AI.

👁️ 3. Attention: Teaching the Model Where to Look

There is an important chronological detail here: the attention mechanism did not begin with the Transformer.

Around 2014, particularly in neural machine translation research, models began to learn how to focus more heavily on relevant parts of the source sentence while generating each part of the output.

This idea was extremely important because a model no longer had to compress the entire input into a single fixed representation.

⚡ 4. 2017: Attention Is All You Need

In 2017, the publication of Attention Is All You Need became one of the most important turning points in the history of artificial intelligence.

The Transformer architecture greatly reduced the dependence on the sequential processing used by RNNs and placed self-attention at the center of the architecture.

With self-attention, relationships between different words in a text could be modeled directly, while computations could be parallelized far more efficiently.

Today, the architectural roots of major model families such as GPT, Claude, Gemini, Llama, Qwen, and Mistral can largely be traced back to this transformation.

📚 5. Pre-Training and the Foundation Model Paradigm

After the Transformer, another major paradigm gained momentum.

Instead of training a separate model from scratch for every task, researchers began training large general-purpose models on massive datasets and then adapting them to different downstream tasks.

Models such as BERT demonstrated how powerful this approach could be in natural language processing.

The discussion gradually moved beyond the question of “Which architecture performs better?” toward a broader question: “Can we train general-purpose models capable of performing many different tasks?”

📈 6. Scaling and GPT-3

Around 2020, the relationship between model size, training data, computational resources, and performance became far more visible.

Scaling law research suggested that larger models did not simply perform the same tasks slightly better. In some cases, new capabilities appeared as scale increased.

GPT-3 made another important phenomenon highly visible:

A model could perform many different tasks without being retrained for each one, simply by receiving instructions or a few examples in the prompt.

Zero-shot and few-shot prompting became increasingly important.

📄 7. RAG: Moving Beyond the Model’s Parameters

One of the major limitations of large language models was their inability to reliably access current, organization-specific, or previously unseen information.

Retrieval-Augmented Generation, or RAG, approached this problem from a different direction.

Instead of trying to encode every piece of information inside the model’s parameters, relevant information could be retrieved from an external knowledge source and added to the model’s context.

Over time, RAG evolved into more sophisticated architectures involving embeddings, vector databases, semantic search, hybrid search, reranking, query rewriting, and knowledge bases.

This approach remains extremely important today, particularly in enterprise AI applications.

🎨 8. Diffusion Models and Generative Visual AI

Meanwhile, the AI revolution was not limited to text.

With the rise of diffusion models, text-to-image generation rapidly became mainstream.

This was followed by major progress in image editing, style transfer, image-to-video generation, text-to-video generation, speech synthesis, and AI-generated music.

The concept of Generative AI was no longer limited to models that generated text.

👀 9. Multimodal Models

The next important step was bringing different types of data together within the same model.

The model was no longer limited to understanding the text we typed.

📷 It can understand photographs.

📊 It can interpret charts.

📑 It can read documents.

🎙️ It can understand audio.

🖥️ It can see a computer screen.

🎥 It can analyze video.

Because the real world is not composed only of text, multimodality became an essential step toward more general-purpose artificial intelligence.

💬 10. 2022: ChatGPT Brings AI to the Masses

The release of ChatGPT on November 30, 2022 was, in my view, not only a technological milestone but also a major social turning point.

For the first time, large language models entered the daily lives of ordinary users at massive scale.

Teachers, students, doctors, lawyers, engineers, managers, artists, software developers, and entrepreneurs all began interacting with the same technology.

Instruction tuning and alignment methods based on human feedback made interaction with these systems far more natural from the user’s perspective.

At the same time, a new term entered everyday vocabulary:

Prompt Engineering.

🔧 11. Function Calling and Tool Use

Large language models could generate highly impressive text, but their ability to interact with real-world systems was limited.

Function calling and tool use began to change that.

A model could now call an API, access a database, use a calculator, perform a web search, or invoke another software component.

Old approach: “Answer the question.”

New approach: “Use tools when necessary to solve the problem.”

This seemingly small change later became one of the foundations of agentic systems.

🧠 12. Reasoning Models

In 2024, the rise of reasoning models introduced another important shift.

The focus was no longer only on adding more parameters to the model. Models could also spend more computation on a difficult problem before producing an answer.

The concept of test-time compute became increasingly important.

Especially in mathematics, science, coding, and complex problem solving, the idea of the “larger model” was joined by another idea: the “model that spends more time reasoning about the problem.”

💻 13. From Chatbot to Coding Agent

In my view, one of the most important recent transformations has occurred in software development.

At first, we asked models to generate small pieces of code.

Then came copilot-style systems embedded directly inside IDEs.

Later, AI systems began reading entire repositories, creating files, running terminal commands, debugging errors, writing tests, and refactoring code.

💬 A system that talks about code

➡️ A system that suggests code

➡️ A system that writes code

➡️ A system that works across a repository

➡️ An agent that takes responsibility for a software development task

🔌 14. MCP: Standard Connections Between AI and the Outside World

As agent systems became more common, another problem became increasingly visible.

Every AI application had to be integrated separately with GitHub, file systems, databases, enterprise applications, and many other external services.

The Model Context Protocol, or MCP, became an important development for establishing more standardized connections between AI applications, tools, and data sources.

I do not think MCP should be viewed merely as a technical protocol. For an agent ecosystem to grow, models need standardized and manageable ways to connect to the outside world.

🧩 15. Agent Skills

The next step was to stop explaining the same procedures to an agent again and again, and instead define reusable skills that describe how particular tasks should be performed.

A skill can, for example, teach an agent:

📊 How to analyze an Excel file,

📄 How to prepare a professional report,

🧪 How to execute a testing procedure,

🏢 How to follow an organization-specific workflow,

💻 How to perform a particular software development task.

The agent can then use that skill whenever it becomes relevant.

This seems especially important in the transition from general-purpose AI toward specialized digital workers.

🖥️ 16. Computer Use and Browser Use

Agents then began doing more than simply calling APIs.

They started seeing screens, moving the mouse, clicking buttons, navigating websites, and interacting with the same graphical user interfaces that humans use.

I believe this is a critical development.

Most software in the world does not have an API specifically designed for AI. But almost every application has a user interface designed for humans.

With computer use, the user interface itself is effectively becoming another integration layer that AI systems can operate.

🌍 17. Open Models and Local AI

While all of these developments were taking place, another transformation was happening in parallel.

Open-weight models rapidly narrowed the gap with closed models across many practical use cases.

Model families such as Llama, Mistral, Qwen, and DeepSeek helped build a powerful open ecosystem.

Quantization, more efficient inference engines, and advances in hardware made it possible to run models locally that previously would have required large data centers.

Artificial intelligence no longer has to exist only as a cloud service accessed over the internet.

Local AI systems that keep organizational or personal data on-premise are becoming increasingly realistic alternatives.

The emergence of personal agent software that can run continuously on a local computer is another important part of this transformation.

🤖 18. 2026: The Year of AI Agents

For some time, many people had predicted that 2026 would become “the year of AI agents.”

I think that prediction has largely come true.

However, the meaning of the word “agent” has also changed.

Early agent architectures looked roughly like this:

LLM → call a tool → observe the result → call another tool if necessary → answer

Today, we are talking about far more comprehensive systems.

🧭 They can plan.

🧰 They can choose the right tool.

🗂️ They can manage files and context.

🧠 They can preserve state across a task.

🤝 They can delegate work to other agents.

💻 They can run code and terminal commands.

🌐 They can perform actions on the web.

🔍 They can evaluate their own outputs.

🛡️ They can operate within permission boundaries.

👤 They can request human approval when necessary.

🏗️ 19. The Next Step: Agent Harnesses

One concept I find particularly important in recent developments is the agent harness.

As we assign agents longer and more complicated tasks, the intelligence of the underlying model alone is no longer enough.

A model can perform extremely well during the first few steps and then drift in the wrong direction.

It can incorrectly assume that the task is complete.

It can forget previous decisions.

It can reach a conclusion without testing its work.

Its context can gradually degrade during long-running tasks.

This is why we increasingly need an execution environment around the model that manages and supervises its work.

📝 It preserves the plan.

🔄 It triggers replanning when necessary.

🧪 It tests intermediate and final results.

🔍 It checks for missing work.

📚 It manages context.

📈 It monitors progress.

✅ It can independently verify the output.

🛑 It helps determine when the agent should stop.

This moves us from chatbots that work for a few minutes toward AI systems that can work toward a goal for hours, or potentially much longer when supported by the right infrastructure.

I THINK THIS IS THE REAL BREAKTHROUGH

The competition is no longer simply about “who has the best LLM?”

The real competition is about how effectively a model can operate with the right data, the right tools, the right memory, the right skills, the right security mechanisms, and the right verification environment.

How Has the Short History of Modern AI Actually Changed?

🧠 2010s → The model recognizes patterns.

💬 2022 → The model talks to us.

👀 2023–2024 → The model sees and hears.

🧠 2024 → The model spends more time reasoning about the problem.

🔧 2023–2025 → The model uses tools.

🖥️ 2024–2025 → The model uses computers and browsers.

🤖 2025–2026 → The model becomes an agent.

🏗️ 2026 → The agent is placed inside an environment designed for long-running work.

🔮 So What Will Define AI in 2027?

I do not think the next major leap will necessarily be just another, slightly more powerful conversational model.

One of my strongest candidates is the persistent agent: a personal or enterprise AI system that can work continuously while preserving its state and context over time.

In today’s chatbot paradigm, we go to the AI.

We open a window, ask a question, receive an answer, and then continue working ourselves.

The next stage may be very different: AI could become a persistent part of our working environment.

🧠 It could recall our previous work when relevant.

📧 It could work with our email and messages.

📅 It could follow calendars and tasks.

📁 It could understand our files and projects.

🌐 It could conduct research when necessary.

💻 It could perform actions on our computers.

🧩 It could use the skills it needs.

🔌 It could connect to enterprise systems.

🤝 It could collaborate with specialized agents.

🛡️ It could understand its permission boundaries.

👤 It could request human approval for critical actions.

✅ It could verify its own work before reporting completion.

☁️ Cloud or Local?

I also do not think this future will be entirely cloud-based.

As personal and enterprise data becomes more important, hybrid architectures will probably become increasingly attractive.

Small and fast models may run continuously on local devices.

When more complex reasoning is required, the system could call more powerful cloud models.

Organization-specific knowledge could remain on-premise.

Highly sensitive tasks could be handled entirely by local models.

In the future, instead of asking “Which model are you using?” we may increasingly ask: “What kind of AI architecture is your system running on?”

🤖 Another Strong Candidate: Physical AI

Another major field to watch is artificial intelligence moving beyond the computer screen and into the physical world.

When vision, reasoning, planning, and agent technologies are combined with robotics, we may see major advances in embodied AI or physical AI.

An agent that learns how to click a button on a computer screen today and an AI system that controls a physical robot tomorrow may be more closely related problems than they first appear.

🚀 Perhaps the Most Important Part of the Revolution Is Just Beginning

When I look back at the developments of the past 15 years, the most interesting change for me is how our questions have changed.

During the Deep Learning era, we asked:

“Can the machine recognize this?”

During the LLM era, the question became:

“Can the machine understand and explain this?”

With reasoning models, we started asking:

“Can the machine solve this problem?”

In the age of agents, the question is very different:

“Can I give this entire task to AI from beginning to end?”

I do not think this is a small change.

For most of the history of computing, humans learned how to use computers.

Now computers are beginning to learn how to use the same tools that we use.

Perhaps the most important transformation of the next few years will happen precisely here.

🤔 What Is Your Prediction?

Which technology or approach do you think will become the defining AI trend of 2027?

🤖 Persistent personal AI agents?

🏢 Enterprise agent systems?

🏗️ Agent harnesses and long-running autonomous work?

🧠 More powerful reasoning models?

🖥️ Computer use and browser use?

🌍 Open and locally running models?

🤖 Physical AI and robotics?

Or will the next major breakthrough come from something that we are not yet talking about enough?

Selected Milestones

Krizhevsky, Sutskever & Hinton — ImageNet Classification with Deep Convolutional Neural Networks, 2012

Sutskever, Vinyals & Le — Sequence to Sequence Learning with Neural Networks, 2014

Bahdanau, Cho & Bengio — Neural Machine Translation by Jointly Learning to Align and Translate, 2014

Vaswani et al. — Attention Is All You Need, 2017

Devlin et al. — BERT, 2018

Kaplan et al. — Scaling Laws for Neural Language Models, 2020

Brown et al. — Language Models are Few-Shot Learners, 2020

Lewis et al. — Retrieval-Augmented Generation, 2020

Ho, Jain & Abbeel — Denoising Diffusion Probabilistic Models, 2020

#MuratKarakayaAkademi #ArtificialIntelligence #GenerativeAI #LLM #AIAgents #AgenticAI #DeepLearning #Transformer #ReasoningModels #RAG #MCP #AgentSkills #ComputerUse #OpenSourceAI #LocalAI #AIEngineering #FutureOfAI

Artificial Intelligence • R&D • Project Management

noreply@blogger.com (Murat Karakaya) — Sat, 26 Sep 2026 20:05:40 +0000

Artificial Intelligence • R&D • Project Management

```

🚨 Why Do AI Projects Fail?

Project proposals are becoming increasingly impressive. But can we say the same about the engineering capacity of the teams expected to turn those proposals into working systems?

```

Recently, I have been noticing the same problem more and more often during project evaluations.

When you start reading an AI-related project proposal, you often see almost every recent method, technique, and technology somehow included in the project:

Large language models, RAG, AI agents, vector databases, personalization, fine-tuning, multi-agent architectures, real-time analytics, prediction systems, decision support, explainable AI...

On paper, the project looks highly impressive.

However, once you meet the team face to face and begin asking more detailed questions, a very different picture often emerges.

👥 The technology is in the proposal — but is the experience in the team?

Sometimes, the engineers on the project team have never developed even a small-scale application using the technologies described in the proposal.

The company itself may also have no prior experience building, deploying, operating, or maintaining products based on those methods.

After a few questions, the following issues begin to surface:

Why was this technology selected?
What real problem does it solve in the project?
Why is it being used together with the other components?
Were alternative methods evaluated?
How will success be measured?
If the system fails, how will the team determine which component failed and why?

Unfortunately, in some projects, there are no clear answers.

The technology choices appear to be less the result of an engineering analysis and more the result of connecting fashionable concepts to one another.

💡 The problem is not that too many technologies are being used. The problem is that the team cannot explain, from an engineering perspective, why each technology is actually necessary.

🧩 A list of technologies is not a system design

Today, it is relatively easy to produce impressive project documents with generative AI.

You can list the advantages of every technology. You can summarize their benefits from the literature. You can draw an architecture with a few boxes and arrows.

But none of this, by itself, constitutes systems engineering.

In a real system design, every component has a reason to exist.

A component should not be added because it is fashionable. It should be added because it satisfies a specific requirement.

For every selected method, the team should be able to explain:

which requirement it addresses,
which alternatives it was compared against,
which metric it is expected to improve,
which costs it introduces,
and which new risks it adds to the system.

Otherwise, what we have is not a system architecture. It is merely a list of current technologies.

🔍 Saying “we will use RAG” is easy. Building a working RAG system is not.

For example, the following sentence has become very common in AI project proposals:

“A RAG-based artificial intelligence system will be developed to generate reliable answers from corporate documents.”

Fine.

But the real engineering problem begins exactly where that sentence ends.

📌 How will system performance be measured?

📌 How will the benchmark dataset be created?

📌 How will real user questions be represented in the evaluation set?

📌 How will retrieval quality be separated from final answer quality?

📌 How will chunk size and overlap be selected?

📌 Which experiment will determine the embedding model?

📌 Which metadata fields will distinguish text chunks from tens of thousands of documents?

📌 If multiple versions of the same document exist, which one will be used?

📌 How will obsolete or withdrawn information be removed from the system?

📌 How will unauthorized users be prevented from retrieving restricted content?

📌 How will hallucination be measured?

📌 How should the system behave when a reliable answer cannot be generated?

📌 How will latency be controlled under thousands of concurrent users?

📌 How will the trade-off between cost, accuracy, and response time be managed?

Every one of these is a real-world engineering problem.

Yet in many project documents, instead of answering these questions, the proposal simply explains the generic benefits of RAG.

That tells us that the project may be conceptually defined, but its operational reality has not been sufficiently considered.

⚠️ Using AI to prepare a project is not the same as developing an AI project

I believe a new risk has emerged in recent years.

Generative AI has made project preparation dramatically easier.

Literature reviews, technology descriptions, methodology sections, and technical documentation that once took weeks can now be produced much faster.

This is not inherently a bad development.

On the contrary, when used properly, it can create enormous productivity gains.

The problem begins when the process turns into something like this:

🤖 Ask AI to write the project proposal.

💰 Apply for funding.

🧑‍💻 If the funding is approved, ask AI to write the code too.

This mindset can easily turn into a dangerous form of shortcut-driven project development.

The engineering gap between a project proposal and a real system cannot automatically be closed simply by using more AI.

🧠 AI does not automatically create experience that the team does not have

Today’s generative AI systems can write code, suggest architectures, create APIs, generate test scenarios, and produce documentation.

But there is still a critical distinction:

AI can generate a solution for you. But determining whether that solution is actually the right solution for your problem still requires knowledge and experience.

Because real engineering is not simply about generating code.

Real engineering means:

defining the right problem,
identifying the requirements,
comparing alternative approaches,
defining measurable success criteria,
anticipating bottlenecks,
handling unexpected cases,
testing the system under real user behavior,
and considering scalability and sustainability.

📉 So what happens in the end?

A system that looked extremely strong in the project proposal fails to deliver the expected performance during implementation.

At first, a few demonstrations are prepared.

The system performs well on carefully selected examples.

But once real data, real users, and real operational conditions enter the picture, problems begin to appear.

Costs increase.

Latency rises.

Data quality problems emerge.

Authorization requirements become important.

The model begins producing unexpected answers.

Real user questions do not resemble the clean examples used in demonstrations.

And because there is no properly designed benchmark, the team may not even know which change actually improves the system.

As time passes, the project schedule slips.

The team changes.

Employees leave.

New team members do not understand why previous architectural decisions were made.

Eventually, the project is either scaled down, diverted from its original objective, or left behind as an unused prototype.

🎯 Perhaps we are asking the wrong question

When evaluating AI projects, we often focus on this question:

“Which technologies will be used in the project?”

I believe there is a more important question:

“Does this team actually have the engineering capacity to build the system described in the proposal?”

This should be followed by several additional questions:

Has the team solved a similar problem before?
Has it at least built a small-scale prototype?
Does the team understand the technical risks?
Does it know which assumptions may turn out to be wrong?
Can it design experiments to measure success?
Does it know how to validate the system under real user load?

🏗️ How should a good AI project begin?

In my view, the process should begin with the problem, not with technology names.

Wrong starting point	A better starting point
“Let’s use RAG.”	“Let’s understand which information users cannot access and why.”
“Let’s add agents.”	“Let’s identify which tasks genuinely require multi-step reasoning and decision-making.”
“Let’s personalize everything with an LLM.”	“Let’s measure which user information actually improves response quality.”
“Let’s use the most powerful model.”	“Let’s experimentally determine the right trade-off between quality, cost, and latency.”

🚀 A strong project proposal does not necessarily mean a strong project

Today, it is possible to prepare an excellent project proposal with the help of AI.

In fact, compared with just a few years ago, proposals can now be more professional, more technical, and far more persuasive.

But the quality of the proposal and the feasibility of the project are not the same thing.

AI can accelerate project preparation.

It can accelerate software development.

It can simplify documentation.

It can generate test scenarios.

It can suggest architectural alternatives.

But it does not magically create engineering experience, domain knowledge, systems thinking, or product development culture that the team does not already possess.

🎯 One of the biggest risks in AI projects may no longer be lack of access to technology. It may be the opposite: because access has become so easy, teams may begin highly ambitious projects without sufficient preparation or experience.

At the end of the day, we still need people who understand the problem, ask the right questions, design meaningful measurements, anticipate failure points, and architect the system from end to end.

💬 Have you also encountered AI projects that look extremely strong in project documentation but fail to translate into real-world systems?

#MuratKarakayaAkademi #ArtificialIntelligence #AI #GenerativeAI #LLM #RAG #AgenticAI #Engineering #SystemsEngineering #ProjectManagement #ResearchAndDevelopment #ProductDevelopment #AIProjects #Innovation #Technology

Yapay Zekanın Yolculuğu

noreply@blogger.com (Murat Karakaya) — Sat, 26 Sep 2026 19:56:23 +0000

YAPAY ZEKÂ • LLM • AGENTIC AI • 2027

Yapay Zekâdaki Devrimi Yaşarken Fark Etmek: Deep Learning’den Uzun Süre Çalışan Agent’lara

Son 15 yılda yapay zekâ yalnızca daha başarılı modeller üretmedi. Görüntüyü tanıyan sistemlerden konuşan modellere, konuşan modellerden araç kullanan agent’lara, oradan da saatlerce hatta günlerce bir problem üzerinde çalışabilen yapay zekâ sistemlerine geçtik. Peki 2027’nin kırılma noktası ne olacak?

Bir sohbetten geriye kalan soru

Bugün yapay zekâya meraklı bir dostumla sohbet ederken konu doğal olarak son yıllarda bu alanda yaşanan baş döndürücü gelişmelere geldi.

Bir süre sonra geçmişte hangi teknolojileri konuştuğumuzu hatırlamaya başladık. Deep Learning, RNN, LSTM, Transformer, büyük dil modelleri, multimodal modeller, reasoning modeller, RAG, function calling, agent’lar, MCP, computer use, coding agent’ları ve son olarak uzun süre çalışabilen agent sistemleri...

Hepsini arka arkaya sıraladığımızda değişimin hızını daha net fark ediyorsunuz.

Aslında son birkaç yılda yalnızca daha başarılı yapay zekâ modelleri geliştirmedik. Yapay zekâyı kullanma biçimimiz de birkaç kez tamamen değişti.

Yapay zekâ, örüntüleri tanıyan bir sistemden bizimle konuşan bir sisteme, oradan düşünen, araç kullanan ve giderek kendi başına iş yapabilen bir sisteme dönüşüyor.

🧠 1. Deep Learning: Büyük kırılmanın başlangıcı

Yapay sinir ağları elbette yeni değildi. Ancak uzun yıllar boyunca yeterli veri, hesaplama gücü ve uygun eğitim tekniklerinin bulunmaması nedeniyle potansiyellerinin önemli bir kısmını gösterememişlerdi.

2012’de AlexNet’in ImageNet yarışmasında elde ettiği başarı, GPU üzerinde eğitilen çok katmanlı yapay sinir ağlarının ne kadar güçlü olabileceğini gösterdi.

Computer vision alanında başlayan bu sıçrama kısa sürede konuşma tanıma, doğal dil işleme ve diğer makine öğrenmesi problemlerine yayıldı.

Bugünden baktığımızda basit görünebilir ama bugün yaşadığımız yapay zekâ devriminin önemli başlangıç noktalarından biri burada oluştu:

Daha büyük ağlar + daha fazla veri + daha fazla hesaplama gücü.

🔁 2. RNN, LSTM ve Sequence-to-Sequence

Görüntülerde CNN mimarileri büyük başarı gösterirken doğal dil tarafında farklı bir sorun vardı. Dil sıralı bir yapıydı.

RNN ve özellikle LSTM gibi mimariler geçmişten gelen bilgiyi belirli ölçüde taşıyarak cümleler, konuşmalar ve zaman serileri üzerinde çalışmayı mümkün hale getirdi.

Ardından sequence-to-sequence, yani seq2seq mimarileri geldi. Bir diziyi alıp başka bir dizi üretmek mümkün hale geldi. Makine çevirisi bunun en önemli uygulamalarından biri oldu.

Bugün bir modele verdiğimiz metnin karşılığında yeni bir metin üretmesini çok doğal karşılıyoruz. Ancak bugünkü üretken modellerin geçmişindeki önemli basamaklardan biri encoder-decoder ve seq2seq çalışmalarıydı.

👁️ 3. Attention: Model nereye bakması gerektiğini öğreniyor

Burada kronolojik olarak önemli bir ayrıntı var. Attention mekanizması Transformer ile başlamadı.

2014 civarında özellikle neural machine translation çalışmalarında modelin kaynak cümlenin her bölümüne aynı şekilde yaklaşmak yerine, çıktı üretirken ilgili bölümlere daha fazla dikkat verebilmesi gösterildi.

Bu fikir son derece önemliydi. Çünkü model artık bütün girdiyi tek bir sabit temsil içerisine sıkıştırmak zorunda değildi.

⚡ 4. 2017: Attention Is All You Need

2017’de yayımlanan Attention Is All You Need makalesi yapay zekâ tarihinin en önemli dönüm noktalarından biri oldu.

Transformer mimarisi, RNN’lerdeki sıralı işleme bağımlılığını büyük ölçüde ortadan kaldırdı ve self-attention mekanizmasını merkeze aldı.

Self-attention sayesinde bir metindeki farklı kelimeler arasındaki ilişkiler doğrudan modellenebiliyor ve hesaplamalar çok daha verimli biçimde paralelleştirilebiliyordu.

Bugün kullandığımız GPT, Claude, Gemini, Llama, Qwen, Mistral ve benzeri büyük model ailelerinin mimari köklerinde büyük ölçüde bu dönüşüm bulunuyor.

📚 5. Pre-training ve Foundation Model yaklaşımı

Transformer’dan sonra başka bir paradigma güç kazandı.

Her görev için ayrı bir model eğitmek yerine, çok büyük veri kümeleri üzerinde genel amaçlı bir model eğitip daha sonra bunu farklı görevlere uyarlamak.

BERT gibi modeller bu yaklaşımın doğal dil işlemede ne kadar güçlü olabileceğini gösterdi.

Böylece tartışma yalnızca “hangi mimari daha başarılı?” sorusundan uzaklaşıp, çok sayıda görevi gerçekleştirebilecek genel amaçlı modeller geliştirmeye doğru kaydı.

📈 6. Scaling ve GPT-3

2020 civarında model büyüklüğü, eğitim verisi ve hesaplama gücünün artırılmasıyla performans arasındaki ilişki çok daha görünür hale geldi.

Scaling laws çalışmaları, daha büyük modellerin yalnızca aynı görevleri biraz daha iyi yapmadığını, bazı yeni yeteneklerin de model ölçeği arttıkça ortaya çıkabildiğini gösteriyordu.

GPT-3 ise başka bir önemli özelliği görünür hale getirdi:

Bir modele her görev için yeniden eğitim vermeden, yalnızca talimat ve birkaç örnek aracılığıyla çok farklı görevler yaptırılabiliyordu.

Zero-shot ve few-shot kullanım giderek daha önemli hale geldi.

📄 7. RAG: Modelin parametrelerinin dışına çıkmak

Büyük dil modellerinin önemli problemlerinden biri güncel, kuruma özel veya modelin eğitiminde bulunmayan bilgiye erişememeleriydi.

Retrieval-Augmented Generation, yani RAG yaklaşımı bu problemi farklı bir şekilde ele aldı.

Her bilgiyi modelin parametrelerine koymak yerine, soruyla ilgili bilgi dışarıdaki bir bilgi kaynağından bulunuyor ve modelin context’ine ekleniyordu.

Daha sonra embedding, vector database, semantic search, hybrid search, reranking, query rewriting ve knowledge base mimarileriyle RAG çok daha gelişmiş bir yapıya dönüştü.

Özellikle kurumsal yapay zekâ uygulamalarında bu yaklaşım bugün hâlâ son derece önemli.

🎨 8. Diffusion modelleri ve üretken görsel yapay zekâ

Bu sırada yapay zekâ devrimi yalnızca metin üzerinde ilerlemiyordu.

Diffusion modellerinin gelişmesiyle metinden görüntü üretmek çok hızlı biçimde yaygınlaştı.

Ardından görüntü düzenleme, stil değiştirme, görselden video üretme, metinden video üretme, ses sentezi ve müzik üretimi gibi alanlarda hızlı ilerlemeler yaşandı.

Generative AI kavramı artık yalnızca metin üreten modelleri ifade etmiyordu.

👀 9. Multimodal modeller

Bir sonraki önemli adım farklı veri türlerinin aynı model içerisinde bir araya gelmesi oldu.

Model artık yalnızca yazdığımız metni anlamıyordu.

📷 Fotoğrafları anlayabiliyor.

📊 Grafikleri yorumlayabiliyor.

📑 Belgeleri okuyabiliyor.

🎙️ Sesi anlayabiliyor.

🖥️ Bilgisayar ekranını görebiliyor.

🎥 Videoları analiz edebiliyor.

Gerçek dünya yalnızca metinden oluşmadığı için multimodalite yapay zekânın genel amaçlı hale gelmesi açısından çok önemli bir adımdı.

💬 10. 2022: ChatGPT ile yapay zekâ geniş kitlelerle buluştu

30 Kasım 2022’de ChatGPT’nin kullanıma açılması bence teknolojik olduğu kadar toplumsal bir kırılma noktasıydı.

Büyük dil modelleri ilk kez bu ölçekte sıradan kullanıcıların günlük hayatına girdi.

Öğretmenler, öğrenciler, doktorlar, avukatlar, mühendisler, yöneticiler, sanatçılar ve yazılımcılar aynı teknolojiyle konuşmaya başladı.

Instruction tuning ve insan geri bildirimiyle hizalama gibi çalışmalar sayesinde kullanıcı açısından çok daha doğal bir etkileşim ortaya çıktı.

Aynı dönemde yeni bir kavram da günlük dilimize girdi:

Prompt Engineering.

🔧 11. Function Calling ve Tool Use

Büyük dil modelleri çok etkileyici metinler üretebiliyordu. Ancak gerçek dünyadaki sistemlerle etkileşimleri sınırlıydı.

Function calling ve tool use yaklaşımı bunu değiştirmeye başladı.

Model artık bir API çağırabiliyor, veritabanına erişebiliyor, hesaplama aracı kullanabiliyor, arama yapabiliyor veya başka bir yazılım bileşenini çalıştırabiliyordu.

Eski yaklaşım: “Soruyu cevapla.”

Yeni yaklaşım: “Problemi çözmek için gerekiyorsa araç kullan.”

Bu küçük görünen değişim daha sonra agent sistemlerinin temelini oluşturdu.

🧠 12. Reasoning modeller

2024’te reasoning modellerin yaygınlaşmasıyla başka bir paradigma daha ortaya çıktı.

Artık yalnızca modele daha fazla parametre eklemekten değil, modelin cevap vermeden önce problem üzerinde daha fazla hesaplama yapmasından söz ediyorduk.

Test-time compute kavramı önem kazandı.

Özellikle matematik, bilim, kodlama ve karmaşık problem çözme alanlarında “daha büyük model” yaklaşımının yanına “problem üzerinde daha uzun çalışan model” yaklaşımı eklendi.

💻 13. Chatbot’tan Coding Agent’a

Bence yakın dönemin en önemli dönüşümlerinden biri yazılım geliştirme alanında gerçekleşti.

İlk aşamada modellerden kod parçaları istemeye başladık.

Sonra IDE içerisine yerleşen copilot sistemleri geldi.

Daha sonra yapay zekâ bütün repository’yi okumaya, dosya oluşturmaya, terminal çalıştırmaya, hata ayıklamaya, test yazmaya ve kodu yeniden düzenlemeye başladı.

💬 Kod hakkında konuşan sistem

➡️ Kod öneren sistem

➡️ Kod yazan sistem

➡️ Repository üzerinde çalışan sistem

➡️ Yazılım geliştirme görevini üstlenen agent

🔌 14. MCP: Yapay zekâ ile dış dünya arasında standart bağlantılar

Agent sistemleri yaygınlaştıkça başka bir problem ortaya çıktı.

Her yapay zekâ uygulamasını GitHub, dosya sistemi, veritabanı, kurumsal yazılımlar ve farklı servislerle ayrı ayrı entegre etmek gerekiyordu.

Model Context Protocol, yani MCP, yapay zekâ uygulamaları ile araçlar ve veri kaynakları arasında daha standart bağlantılar kurulabilmesi açısından önemli bir gelişme oldu.

Bence MCP’yi yalnızca teknik bir protokol olarak görmemek gerekiyor. Agent ekosisteminin büyümesi için modellerin dış dünyaya standart ve yönetilebilir biçimde bağlanması çok önemli.

🧩 15. Agent Skills

Sonraki aşamada agent’lara belirli işleri nasıl yapacaklarını tekrar tekrar açıklamak yerine yeniden kullanılabilir beceriler tanımlama yaklaşımı güç kazandı.

Bir skill örneğin:

📊 Bir Excel dosyasının nasıl analiz edileceğini,

📄 Profesyonel bir raporun nasıl hazırlanacağını,

🧪 Bir test sürecinin nasıl yürütüleceğini,

🏢 Kuruma özel bir prosedürün nasıl uygulanacağını,

💻 Belirli bir yazılım geliştirme işinin nasıl yapılacağını

agent’a gerektiği anda öğretebiliyor.

Bu yaklaşım genel amaçlı yapay zekâdan uzmanlaşmış dijital çalışanlara geçiş açısından oldukça önemli görünüyor.

🖥️ 16. Computer Use ve Browser Use

Daha sonra agent’lar yalnızca API kullanmakla kalmadı.

Ekranı görmeye, fareyi hareket ettirmeye, butonlara basmaya, web sayfalarında gezinmeye ve bizim kullandığımız grafik kullanıcı arayüzlerini kullanmaya başladı.

Bu bence çok kritik bir gelişme.

Çünkü dünyadaki yazılımların büyük kısmının yapay zekâ için hazırlanmış API’leri yok. Ancak neredeyse hepsinin insanlar için geliştirilmiş bir kullanıcı arayüzü var.

Computer use ile birlikte kullanıcı arayüzünün kendisi bir anlamda yapay zekânın kullanabileceği yeni bir entegrasyon katmanına dönüşüyor.

🌍 17. Açık modeller ve lokal yapay zekâ

Bütün bu gelişmeler devam ederken paralel bir dönüşüm daha yaşandı.

Açık ağırlıklı modeller, kapalı modellerle aralarındaki farkı birçok kullanım alanında hızla azalttı.

Llama, Mistral, Qwen, DeepSeek ve benzeri model aileleri güçlü bir açık ekosistem oluşturdu.

Quantization, daha verimli inference motorları ve donanım gelişmeleri sayesinde daha önce yalnızca büyük veri merkezlerinde çalıştırılabilecek modeller kişisel bilgisayarlarda ve kurum içi sunucularda çalışmaya başladı.

Yapay zekâ artık yalnızca internet üzerinden eriştiğimiz bir bulut servisi olmak zorunda değil.

Verinin kurum dışına çıkmadan işlendiği lokal yapay zekâ sistemleri giderek daha gerçekçi bir seçenek haline geliyor.

Kişisel bilgisayarda sürekli çalışan agent yazılımlarının ortaya çıkması da bu dönüşümün önemli parçalarından biri.

🤖 18. 2026: Agent yılı

2026 için uzun zamandır “agent’ların yılı olacak” deniyordu.

Bence bu tahmin önemli ölçüde gerçekleşti.

Ancak agent kavramının kendisi de değişti.

İlk agent mimarilerinde yapı kabaca şöyleydi:

LLM → araç çağır → sonucu gör → gerekirse başka araç çağır → cevap ver

Bugün ise çok daha kapsamlı sistemlerden söz ediyoruz.

🧭 Planlama yapıyor.

🧰 Doğru aracı seçiyor.

🗂️ Dosyaları ve context’i yönetiyor.

🧠 Durum bilgisini koruyor.

🤝 Başka agent’lara görev verebiliyor.

💻 Kod ve terminal çalıştırabiliyor.

🌐 Web üzerinde işlem yapabiliyor.

🔍 Kendi ürettiği sonucu kontrol edebiliyor.

🛡️ Yetki sınırlarını dikkate alabiliyor.

👤 Gerektiğinde insan onayı isteyebiliyor.

🏗️ 19. Sonraki aşama: Agent Harness

Son dönemde benim özellikle önemli bulduğum kavramlardan biri agent harness.

Çünkü agent’lara daha karmaşık ve uzun görevler vermeye başladığımızda yalnızca modelin ne kadar akıllı olduğu yeterli olmuyor.

Bir model ilk birkaç adımı çok başarılı tamamladıktan sonra yanlış bir yöne gidebilir.

Görevin bittiğini erken düşünebilir.

Önceki kararlarını unutabilir.

Test etmeden sonuca ulaşabilir.

Uzun süreli görevlerde context giderek bozulabilir.

Bu nedenle modelin etrafında onu yöneten bir çalışma ortamına ihtiyaç duyuluyor.

📝 Planı korur.

🔄 Gerektiğinde yeniden planlama yaptırır.

🧪 Sonuçları test eder.

🔍 Eksikleri tekrar kontrol ettirir.

📚 Context yönetimini gerçekleştirir.

📈 Çalışmanın ilerlemesini izler.

✅ Sonucu bağımsız olarak doğrulatabilir.

🛑 Agent’ın ne zaman duracağına karar verilmesine yardımcı olur.

Böylece birkaç dakika boyunca çalışan chatbot yerine saatlerce hatta uygun altyapılarda çok daha uzun süre bir hedef üzerinde çalışabilen sistemlere doğru ilerliyoruz.

BENCE ASIL KIRILMA BURADA

Yarış artık yalnızca “en iyi LLM kimde?” yarışı değil.

Yarış; modeli doğru veri, doğru araçlar, doğru bellek, doğru beceriler, doğru güvenlik mekanizmaları ve doğru doğrulama sistemi içerisinde ne kadar başarılı çalıştırabildiğinizle ilgili.

Yapay zekânın kısa tarihi aslında nasıl değişti?

🧠 2010’lar → Model örüntüleri tanıyor.

💬 2022 → Model bizimle konuşuyor.

👀 2023–2024 → Model görüyor ve duyuyor.

🧠 2024 → Model problem üzerinde daha uzun düşünüyor.

🔧 2023–2025 → Model araç kullanıyor.

🖥️ 2024–2025 → Model bilgisayar ve tarayıcı kullanıyor.

🤖 2025–2026 → Model agent’a dönüşüyor.

🏗️ 2026 → Agent uzun süre çalışabileceği bir sistem içerisine yerleşiyor.

🔮 Peki 2027 neyin yılı olacak?

Bence bir sonraki büyük sıçrama yalnızca yeni ve daha güçlü bir sohbet modeli olmayabilir.

Benim güçlü adaylarımdan biri persistent agent, yani uzun süre çalışan, durumunu ve bağlamını koruyabilen kişisel ve kurumsal yapay zekâ sistemleri.

Bugünkü chatbot yaklaşımında biz yapay zekâya gideriz.

Bir pencere açarız, sorumuzu sorarız ve cevabı aldıktan sonra çalışmaya devam ederiz.

Bir sonraki aşamada ise yapay zekâ çalışma ortamımızın sürekli bir parçası olabilir.

🧠 Geçmiş çalışmalarımızı gerektiğinde hatırlayabilir.

📧 E-posta ve mesajlarla çalışabilir.

📅 Takvim ve görevleri takip edebilir.

📁 Dosya ve projeleri anlayabilir.

🌐 Gerektiğinde araştırma yapabilir.

💻 Bilgisayarda işlem gerçekleştirebilir.

🧩 İhtiyacı olan becerileri kullanabilir.

🔌 Kurumsal sistemlere bağlanabilir.

🤝 Başka uzman agent’larla çalışabilir.

🛡️ Yetki sınırlarını dikkate alabilir.

👤 Kritik işlemlerde insan onayı isteyebilir.

✅ Kendi yaptığı işi doğrulayabilir.

☁️ Bulut mu, lokal mi?

Bunun tamamen bulutta çalışan bir yapı olacağını da düşünmüyorum.

Kişisel ve kurumsal verinin önemi arttıkça hibrit mimarilerin daha anlamlı hale gelmesi muhtemel.

Küçük ve hızlı modeller lokal olarak sürekli çalışabilir.

Daha karmaşık reasoning gerektiğinde güçlü bulut modellerinden destek alınabilir.

Kuruma özel bilgi kurum içerisinde tutulabilir.

Son derece hassas görevler tamamen lokal modellerle yürütülebilir.

Gelecekte “hangi modeli kullanıyorsunuz?” sorusu yerine “yapay zekâ sisteminiz nasıl bir mimari üzerinde çalışıyor?” sorusunu daha fazla sorabiliriz.

🤖 Bir başka güçlü aday: Physical AI

Bir başka önemli gelişme alanı ise yapay zekânın bilgisayar ekranından fiziksel dünyaya çıkması.

Vision, reasoning, planning ve agent teknolojileri robotik sistemlerle birleştiğinde embodied AI veya physical AI alanında büyük gelişmeler görebiliriz.

Bugün bilgisayar ekranındaki bir butona basmayı öğrenen agent’ın yarın fiziksel dünyadaki bir robotu yönlendirmesi aslında birbirinden tamamen bağımsız iki problem değil.

🚀 Belki de devrimin en önemli kısmı daha yeni başlıyor

Son 15 yıldaki gelişime baktığımda benim için en ilginç değişim sorularımızın değişmesi.

Deep Learning döneminde:

“Makine bunu tanıyabilir mi?”

diye soruyorduk.

LLM döneminde:

“Makine bunu anlayıp anlatabilir mi?”

sorusuna geçtik.

Reasoning modellerle:

“Makine bu problemi çözebilir mi?”

diye sormaya başladık.

Agent döneminde ise soru çok daha farklı:

“Bu işi baştan sona yapay zekâya verebilir miyim?”

Bence bu küçük bir değişim değil.

Bilgisayar tarihinin büyük bölümünde insanlar bilgisayarları kullanmayı öğrendi.

Şimdi bilgisayarlar bizim kullandığımız araçları kullanmayı öğrenmeye başlıyor.

Belki de önümüzdeki dönemin asıl dönüşümü burada yaşanacak.

🤔 Sizin tahmininiz nedir?

2027’de yapay zekâda hangi teknoloji veya yaklaşımın öne çıkacağını düşünüyorsunuz?

🤖 Kişisel ve sürekli çalışan AI agent’lar mı?

🏢 Kurumsal agent sistemleri mi?

🏗️ Agent harness ve uzun süreli otonom çalışma mı?

🧠 Daha güçlü reasoning modeller mi?

🖥️ Computer use ve browser use mı?

🌍 Açık ve lokal çalışan modeller mi?

🤖 Physical AI ve robotik mi?

Yoksa bugün henüz yeterince konuşmadığımız tamamen farklı bir kırılma mı geliyor?

Seçilmiş kilometre taşları

Krizhevsky, Sutskever & Hinton — ImageNet Classification with Deep Convolutional Neural Networks, 2012

Sutskever, Vinyals & Le — Sequence to Sequence Learning with Neural Networks, 2014

Bahdanau, Cho & Bengio — Neural Machine Translation by Jointly Learning to Align and Translate, 2014

Vaswani et al. — Attention Is All You Need, 2017

Devlin et al. — BERT, 2018

Kaplan et al. — Scaling Laws for Neural Language Models, 2020

Brown et al. — Language Models are Few-Shot Learners, 2020

Lewis et al. — Retrieval-Augmented Generation, 2020

Ho, Jain & Abbeel — Denoising Diffusion Probabilistic Models, 2020

#YapayZeka #ArtificialIntelligence #GenerativeAI #LLM #AIAgents #AgenticAI #DeepLearning #Transformer #ReasoningModels #RAG #MCP #AgentSkills #ComputerUse #OpenSourceAI #LocalAI #AIEngineering #FutureOfAI

Yapay Zekâ • Ar-Ge • Proje Yönetimi

noreply@blogger.com (Murat Karakaya) — Sat, 26 Sep 2026 19:46:18 +0000

Yapay Zekâ • Ar-Ge • Proje Yönetimi

```

🚨 Yapay Zekâ Projeleri Neden Batıyor?

Proje dosyaları giderek daha etkileyici hale geliyor. Peki aynı şeyi bu projeleri hayata geçirecek ekiplerin mühendislik kapasitesi için de söyleyebilir miyiz?

```

Son zamanlarda proje değerlendirmelerinde giderek daha fazla dikkatimi çeken bir durum var.

Bir proje dosyasını okumaya başladığınızda, özellikle yapay zekâ alanındaki neredeyse bütün güncel kavramların proje içerisine yerleştirildiğini görebiliyorsunuz:

Büyük dil modelleri, RAG, yapay zekâ ajanları, vektör veri tabanları, kişiselleştirme, ince ayar, çoklu ajan mimarileri, gerçek zamanlı analiz, tahminleme, karar destek sistemleri, açıklanabilir yapay zekâ...

Kâğıt üzerinde proje gerçekten etkileyici görünüyor.

Fakat ekip ile yüz yüze görüşmeye geçip biraz daha ayrıntılı sorular sormaya başladığınızda, çoğu zaman bambaşka bir tablo ortaya çıkıyor.

👥 Projede teknoloji var, ama tecrübe var mı?

Bazen projede kullanılacağı belirtilen teknolojilerle ekipteki mühendislerin daha önce küçük ölçekte bile bir uygulama geliştirmediğini görüyorsunuz.

Firmanın da benzer yöntemlerle gerçek bir ürün geliştirme, canlıya alma, kullanıcıya sunma ve operasyon altında çalıştırma konusunda herhangi bir deneyimi bulunmayabiliyor.

Bir süre sonra şu sorular ortaya çıkıyor:

Bu teknoloji neden seçildi?
Projede hangi gerçek problemi çözüyor?
Diğer bileşenlerle neden birlikte kullanılıyor?
Alternatifleri değerlendirildi mi?
Başarılı olup olmadığı nasıl ölçülecek?
Çalışmadığında hangi bileşenin neden çalışmadığı nasıl anlaşılacak?

Ne yazık ki bazen bu soruların net cevapları bulunmuyor.

Çünkü proje dokümanında yer alan teknoloji seçimi, gerçek bir mühendislik analizinin sonucu olmaktan çok, güncel kavramların birbirine bağlanmasıyla oluşturulmuş gibi duruyor.

💡 Sorun, projede çok fazla teknoloji kullanılması değil. Sorun, kullanılan her teknolojinin neden gerekli olduğunun mühendislik açısından açıklanamaması.

🧩 Teknoloji listesi, sistem tasarımı değildir

Günümüzde yapay zekâ araçlarıyla oldukça etkileyici proje metinleri üretmek mümkün.

Her teknolojinin avantajları sıralanabilir. Kullanılan yöntemlerin literatürdeki faydaları anlatılabilir. Mimari birkaç kutu ve okla gösterilebilir.

Fakat bunların hiçbiri tek başına sistem mühendisliği anlamına gelmiyor.

Gerçek bir sistem tasarımında her bileşenin bir gerekçesi vardır.

Bir bileşen, moda olduğu için değil, belirli bir ihtiyacı karşıladığı için sisteme girer.

Seçilen yöntemin:

hangi gereksinimi karşıladığı,
hangi alternatife göre tercih edildiği,
hangi metriği iyileştirmesi beklendiği,
hangi maliyeti oluşturduğu,
hangi yeni riski sisteme eklediği

açıklanabilmelidir.

Aksi halde elimizde bir sistem mimarisi değil, yalnızca güncel teknolojilerin yer aldığı bir liste vardır.

🔍 RAG demek kolay; çalışan bir RAG sistemi geliştirmek zor

Örneğin proje dokümanında şu cümleyi görmek artık oldukça sıradan:

“Kurumsal dokümanlardan güvenilir cevaplar üreten RAG tabanlı yapay zekâ sistemi geliştirilecektir.”

Güzel.

Fakat gerçek mühendislik problemi tam da bu cümlenin bittiği yerde başlıyor.

📌 Sistemin başarısı nasıl ölçülecek?

📌 Benchmark veri seti nasıl hazırlanacak?

📌 Kullanıcıların gerçekten soracağı sorular nasıl temsil edilecek?

📌 Retrieval başarısı ile nihai cevap başarısı birbirinden nasıl ayrılacak?

📌 Chunk büyüklüğü ve overlap değerleri nasıl seçilecek?

📌 Embedding modeli hangi deney sonucuna göre belirlenecek?

📌 On binlerce dokümandaki parçalar hangi metadata alanlarıyla birbirinden ayrılacak?

📌 Aynı belgenin farklı sürümleri varsa hangisi kullanılacak?

📌 Yürürlükten kalkmış bilgi nasıl sistem dışına çıkarılacak?

📌 Yetkisiz kullanıcının erişmemesi gereken içerik retrieval aşamasında nasıl engellenecek?

📌 Hallucination nasıl ölçülecek?

📌 Cevap üretilemediğinde sistem nasıl davranacak?

📌 Binlerce eşzamanlı kullanıcı olduğunda gecikme süresi nasıl kontrol altında tutulacak?

📌 Maliyet, doğruluk ve cevap süresi arasındaki denge nasıl kurulacak?

Bunların her biri gerçek hayatta karşınıza çıkacak mühendislik problemidir.

Fakat bazı proje dosyalarında bu sorulara cevap vermek yerine, RAG teknolojisinin genel faydalarının anlatıldığını görüyoruz.

Bu da bize projenin teorik olarak tanımlandığını, ancak operasyonel gerçekliğinin yeterince düşünülmediğini gösteriyor.

⚠️ Yapay zekâ ile proje hazırlamak başka, yapay zekâ projesi geliştirmek başka

Burada son yıllarda ortaya çıkan yeni bir risk olduğunu düşünüyorum.

Yapay zekâ araçları proje hazırlama sürecini olağanüstü kolaylaştırdı.

Daha önce haftalarca sürebilecek literatür taramaları, teknoloji açıklamaları, yöntem bölümleri ve teknik metinler artık çok daha kısa sürede hazırlanabiliyor.

Bu kendi başına kötü bir gelişme değil.

Tam tersine, doğru kullanıldığında ciddi bir verimlilik sağlıyor.

Problem şu noktada başlıyor:

🤖 Yapay zekâya proje dosyasını yazdır.

💰 Destek başvurusunu yap.

🧑‍💻 Destek çıkarsa kodu da yapay zekâya yazdır.

Bu yaklaşım giderek tehlikeli bir kolaycılığa dönüşebiliyor.

Çünkü proje dokümanı ile gerçek uygulama arasındaki mühendislik boşluğu, yalnızca daha fazla yapay zekâ kullanılarak otomatik olarak kapatılamıyor.

🧠 Yapay zekâ, olmayan tecrübeyi otomatik olarak üretmiyor

Bugünkü üretken yapay zekâ sistemleri kod yazabiliyor, mimari önerebiliyor, API oluşturabiliyor, test senaryosu hazırlayabiliyor ve dokümantasyon üretebiliyor.

Ancak hâlâ çok kritik bir fark var:

Yapay zekâ size bir çözüm üretebilir; fakat o çözümün sizin probleminiz için gerçekten doğru çözüm olup olmadığını değerlendirebilmek için yine bilgiye ve tecrübeye ihtiyacınız vardır.

Çünkü gerçek mühendislik yalnızca kod üretmek değildir.

Gerçek mühendislik:

doğru problemi tanımlamak,
gereksinimleri ortaya çıkarmak,
alternatifleri karşılaştırmak,
ölçülebilir başarı kriterleri belirlemek,
darboğazları önceden görmek,
beklenmeyen durumları yönetmek,
sistemi gerçek kullanıcı davranışı altında test etmek,
ölçeklenebilirlik ve sürdürülebilirliği düşünmek

demektir.

📉 Sonuçta ne oluyor?

Proje dosyasında oldukça güçlü görünen sistem, uygulama aşamasına geldiğinde beklenen performansı vermiyor.

Başlangıçta birkaç demo hazırlanıyor.

Kontrollü örneklerde sistem güzel çalışıyor.

Fakat gerçek veri, gerçek kullanıcı ve gerçek operasyon devreye girdiğinde problemler ortaya çıkmaya başlıyor.

Maliyet yükseliyor.

Gecikme süreleri artıyor.

Veri kalitesi problemleri görülüyor.

Yetkilendirme konusu ortaya çıkıyor.

Model beklenmeyen cevaplar üretmeye başlıyor.

Kullanıcıların sorduğu sorular, demo sırasında hazırlanmış örneklere benzemiyor.

Sistemin başarısını gösterecek düzgün bir benchmark olmadığı için hangi değişikliğin sistemi iyileştirdiği bile anlaşılamıyor.

Zaman geçtikçe proje takvimi kayıyor.

Ekip değişiyor.

Çalışanlar ayrılıyor.

Yeni ekip eski kararların neden alındığını anlamıyor.

Sonunda proje ya küçültülüyor, ya amacından uzaklaşıyor ya da kullanılmayan bir prototip olarak kalıyor.

🎯 Belki de yanlış soruyu soruyoruz

Yapay zekâ projelerini değerlendirirken çoğu zaman şu soruya odaklanıyoruz:

“Projede hangi teknolojiler kullanılacak?”

Bence bundan daha önemli bir soru var:

“Bu ekip, yazdığı sistemi gerçekten geliştirebilecek mühendislik kapasitesine sahip mi?”

Hatta bunun devamında şu sorular da sorulmalı:

Ekip benzer bir problemi daha önce çözmüş mü?
En azından küçük ölçekli bir prototip geliştirmiş mi?
Teknik risklerin farkında mı?
Hangi varsayımların yanlış çıkabileceğini biliyor mu?
Başarıyı ölçmek için deney tasarlayabiliyor mu?
Sistemi gerçek kullanıcı yükü altında nasıl doğrulayacağını biliyor mu?

🏗️ İyi bir yapay zekâ projesi nasıl başlamalı?

Bana göre süreç teknoloji isimleriyle değil, problemle başlamalı.

Yanlış başlangıç	Daha sağlıklı başlangıç
“Projede RAG kullanalım.”	“Kullanıcının hangi bilgiye neden erişemediğini anlayalım.”
“Agent ekleyelim.”	“Hangi görevlerin gerçekten çok adımlı karar gerektirdiğini belirleyelim.”
“LLM ile kişiselleştirelim.”	“Hangi kullanıcı bilgisinin gerçekten cevap kalitesini artırdığını ölçelim.”
“En güçlü modeli kullanalım.”	“Kalite, maliyet ve gecikme arasındaki optimum noktayı deneyle bulalım.”

🚀 Sonuç: Güçlü proje dosyası, güçlü proje demek değildir

Yapay zekâ ile bugün çok iyi bir proje dosyası hazırlamak mümkün.

Hatta belki birkaç yıl öncesine kıyasla çok daha profesyonel, çok daha teknik ve çok daha ikna edici dokümanlar hazırlayabiliyoruz.

Fakat proje dosyasının kalitesi ile projenin uygulanabilirliği aynı şey değil.

Yapay zekâ, proje hazırlama sürecini hızlandırabilir.

Kod geliştirmeyi hızlandırabilir.

Dokümantasyonu kolaylaştırabilir.

Test senaryoları üretebilir.

Mimari alternatifler önerebilir.

Fakat ekibin sahip olmadığı mühendislik tecrübesini, alan bilgisini, sistem düşüncesini ve ürün geliştirme kültürünü sihirli bir şekilde oluşturmaz.

🎯 Yapay zekâ projelerindeki en büyük risklerden biri artık teknolojiye erişememek değil; teknolojiye erişmenin çok kolaylaşması nedeniyle, yeterli hazırlık ve tecrübe olmadan çok iddialı projelere başlanması olabilir.

Günün sonunda hâlâ problemi anlayan, doğru soruları soran, ölçüm yapabilen, hata noktalarını öngörebilen ve sistemi uçtan uca tasarlayabilen insanlara ihtiyacımız var.

💬 Siz de proje dokümanında çok güçlü görünen ancak uygulama aşamasında karşılığı olmayan yapay zekâ projeleriyle karşılaşıyor musunuz?

#MuratKarakayaAkademi #YapayZekâ #ArtificialIntelligence #LLM #RAG #AgenticAI #ArGe #Mühendislik #SistemMühendisliği #ProjeYönetimi #ÜrünGeliştirme #YapayZekâProjeleri #GenerativeAI #Teknoloji #İnovasyon #TÜBİTAK #KOSGEB

EVREN: Türkiye'de Yapay Zekâ Geliştirmek İçin Yeni Bir İmkân

noreply@blogger.com (Murat Karakaya) — Sat, 26 Sep 2026 19:43:09 +0000

Bir yapay zekâ fikriniz var. Hazır bir modeli denemek, kendi verilerinizle bir model eğitmek veya geliştirdiğiniz uygulamaya dil modeli bağlamak istiyorsunuz. Ancak GPU erişimi, sunucu kurulumu ve bunların maliyeti daha başlangıçta önünüze çıkıyor. EVREN, bu ihtiyaçları ortak bir ortamda karşılamayı amaçlayan ve Türkiye'deki araştırmacıların, öğrencilerin ve geliştiricilerin yakından tanıması gerektiğini düşündüğüm bir platform.

Son canlı yayınımda EVREN'i tanıttım ve demosunu yaptım. Kullanım deneyimim sonrasında kişisel değerlendirmem şu: Oldukça olgunlaşmış bir platformla karşı karşıyayız. Bu yazıda EVREN'in sunduğu imkânları, kendi çalışmalarımızda nasıl değerlendirebileceğimizi ve Türkiye açısından neden stratejik önem taşıdığını paylaşmak istiyorum.

Platformu benimle birlikte adım adım incelemek isterseniz canlı yayın kaydını buradan izleyebilirsiniz. Videoyu yazının sonunda da bulabilirsiniz.

Yapay Zeka Ajanınız Neden Başarısız? Seviye 0'dan Seviye 7'ye Ajan Mimarisi

noreply@blogger.com (Murat Karakaya) — Fri, 19 Jun 2026 20:12:26 +0000

Gerçek Yapay Zeka Ajanları Nasıl Tasarlanır? — Seviye 0'dan Seviye 7'ye Adım Adım Kılavuz

Gerçek Yapay Zeka Ajanları (Agents) Nasıl Tasarlanır?

"Persona"lardan Araç Kullanan (Tool-Using) Karar Mekanizmalarına Geçiş
Seviye 0'dan Seviye 7'ye adım adım senior düzeyde AI Engineer rehberi.

Yayınlanma: Haziran 2026 | Okuma süresi: ~25 dk | Kategori: Yapay Zeka Mühendisliği

🎯 Giriş: Neden "Sen Dünyanın En İyi YZ Mühendisisin" Yetersizdir?

İnternetteki eğitimlerin %90'ı size bir ajan yaratmak için şunu yazmanızı söyler:

"Sen dünyanın en iyi yazılım mühendisisin..."

Eğer production'a, yani canlıya bir uygulama çıkacaksanız, sadece persona vererek yazdığınız promptlar sisteminizi bir halüsinasyon bombasına çevirir.

Agent'ların asıl gücü onlara verdiğiniz rollerdan değil; Tool Kullanımı (Araç Kullanımı), Grounding (Temellendirme) ve Açıklanabilirlik (Explainability)'dir.

💡 Bu Yazıda Ne Öğreneceksiniz?

Bu yazıda basit bir problem olan "iki metnin benzerliğini ölçme" görevini alacağız ve acemi bir yaklaşımdan, senior bir YZ mühendisinin tasarlayacağı otonom seviyeye kadar adım adım nasıl geliştireceğimizi göreceğiz. Her seviyede prompt, mimari ve maliyet karşılaştırması yapacağız.

🎬 Video ile Öğrenin: Murat Karakaya Akademi

Bu eğitimi Murat Karakaya Akademi YouTube kanalında da izleyebilirsiniz. Adım adım canlı demo, kod açıklaması ve mimari analiz ile Seviye 0'dan Seviye 7'ye aynı yolculuğu video olarak da takip edebilirsiniz.

▶ YouTube'da İzle — Murat Karakaya Akademi

📌 Seviye 0 — Acemi Yaklaşım: Kara Kutu & Halüsinasyon

Başlangıç

Senaryo: Uygulamamızda üretilen Metin 1 ile Metin 2'nin ne kadar benzer olduğunu 0–100 arasında bulmamız gerekiyor. (Örneğin bir RAG sisteminde, üretilen cevabın referans metne ne kadar sadık olduğunu ölçüyoruz).

Acemi Prompt:
"Sen bir metin analistisin. Sana verilen Metin 1 ve Metin 2'yi karşılaştırıp ne kadar benzer olduklarına karar ver. Benzerliği 0–100 arasında bir sayısal değer ile döndür. 0: Hiç benzemiyorlar, 100: Tamamen kelime kelime aynılar."

Neden Kötü?

Kara Kutu (Black Box): Model sadece "75" döndürdü. Neden 75? 74 veya 80 değil? Bilmiyoruz.
Subjektiflik: Aynı metinlere bir gün 60, ertesi gün 85 verebilir.
Halüsinasyon Riski: LLM'ler matematiksel ölçüm yapamaz; kelime tahmin eder. "75" uydurulmuş bir değerdir.

📌 Seviye 1 — Yapılandırılmış Çıktı & Düşünce Zinciri

İyileştirme

İstediğimiz ilk şey Açıklanabilirlik (Explainability). Modele "bana sadece sonuç verme, düşünme sürecini de ver" diyoruz.

"Sen bir metin analistisin. Amacın iki metnin anlamsal benzerliğini ölçmektir. Çıktını KESİNLİKLE geçerli bir JSON object olarak vermelisin. Markdown veya ek metin kullanma. Zorunlu JSON alanları: - reasoning: Bu iki metne özel benzerlik ve farklılık gerekçesi. - similarity_score: 0-100 arası bir tam sayı. Beklenen JSON şeması: { "type": "object", "required": ["reasoning", "similarity_score"], "properties": { "reasoning": {"type": "string"}, "similarity_score": {"type": "integer", "minimum": 0, "maximum": 100} } }"

Neden Daha İyi?

Chain of Thought (Düşünce Zinciri): Modelden önce skoru istemedik. Önce reasoning alanını doldurmasını istedik. Model açıklamayı yazarken kendi çıkarımını temellendirir.
Hata Ayıklama (Debugging): Skor 40 geldiğinde, "Model şu detayı kaçırmış, o yüzden düşük vermiş" diyebiliriz.
Entegrasyon: JSON çıktısı uygulama kodu tarafından parse edilebilir.

⚠️ Eksik Kalan: Skor hâlâ subjektif. 0–100 arası skala bir LLM için çok geniştir ve kuralsızdır.

📌 Seviye 2 — Rubrik ve Objektivite (Divide & Conquer)

Özerklik Artışı

Agent'ın "benzerlik" gibi soyut bir kavramı kendi başına yorumlamasına izin vermiyoruz. Ona kurallar (rubrik) veriyoruz. Problemi parçalara bölüyoruz.

Rubrik:

1. Ana Fikir (0-20): İki metin aynı ana mesajı mı veriyor?
2. Ton ve Üslup (0-20): İki metnin resmiyeti ve duygusu aynı mı?
3. Varlıklar / Entities (0-20): Metinlerde geçen isimler, tarihler, sayılar eşleşiyor mu?
4. Eksik Bilgi (0-20): Metin 2, Metin 1'deki önemli bir detayı atlamış mı?
5. Akıcılık (0-20): Metin 2 yapısal olarak ne kadar tutarlı?

"Sen uzman bir değerlendiricisin. İki metni yukarıdaki 5 kritere göre değerlendir. Her kriter 0-20 puan arasındadır. Çıktını KESİNLİKLE geçerli bir JSON object olarak üret. Zorunlu JSON alanları: - evaluations: 5 öğeli liste [criterion, score, explanation] - total_score: Beş kriter skorunun toplamı. Beklenen JSON şeması: { "type": "object", "required": ["evaluations", "total_score"], "properties": { "evaluations": { "type": "array", "minItems": 5, "maxItems": 5, "items": { "type": "object", "required": ["criterion", "score", "explanation"], "properties": { "criterion": {"type": "string"}, "score": {"type": "integer", "minimum": 0, "maximum": 20}, "explanation": {"type": "string"} } } }, "total_score": {"type": "integer", "minimum": 0, "maximum": 100} } }"

Neden Daha İyi?

Grounding (Temellendirme): Modeli soyut 100 üzerinden değerlendirmeden kurtardık.
Objektiflik: Farklı zamanlarda çalıştırsanız bile skorlar çok daha tutarlı olur (varyans azalır).
Karşılaştırılabilirlik: Farklı promptları aynı rubrik üzerinden değerlendirebiliriz.

📌 Seviye 3 — Örnekli Rubrik Kalibrasyonu (One-Shot / Few-Shot)

Kalibrasyon

Seviye 2'de rubrik verdik; fakat bu hâlâ sıfır-örnekli prompting (zero-shot prompting) idi. Model kriterleri okudu ama "20 puan ne zaman verilir?", "10 puan hangi sınır durumu?" gibi karar sınırlarını örneklerden görmedi.

Bu seviyede her kriter için küçük ve temsil gücü yüksek örnekler veriyoruz.

Puanlama Kalibrasyonu Örnekleri:

Ana Fikir — 20 puan: "Veri temizliği model başarısı için kritiktir" ve "Model kalitesi büyük ölçüde temiz veriye bağlıdır" aynı ana fikri verir.
Ana Fikir — 10 puan: İki metin de veri kalitesinden söz eder ama biri güvenlik risklerine, diğeri model performansına odaklanır.
Ana Fikir — 0 puan: Biri veri temizliğini, diğeri spor müsabakası sonucunu anlatır.
Ton ve Üslup — 20 puan: İki metin de akademik ve resmi bir dille yazılmıştır.
Ton ve Üslup — 10 puan: Biri resmi, diğeri daha konuşma dilindedir ama anlam korunmuştur.

Neden Daha İyi?

Tutarlılık: Model aynı puan aralıklarını daha kararlı kullanır.
Öğretilebilirlik: Rubrik artık yalnızca soyut bir liste değil, davranış örnekleriyle desteklenmiştir.
Maliyet: Few-shot örnekler giriş tokenını artırır — bu yüzden örnekler kısa ve net seçilir.

Beklenen JSON şeması:

{
  "type": "object",
  "required": ["evaluations", "calibration_note", "total_score"],
  "properties": {
    "evaluations": {
      "type": "array",
      "minItems": 5,
      "maxItems": 5,
      "items": {
        "type": "object",
        "required": ["criterion", "score", "explanation"],
        "properties": {
          "criterion": {"type": "string"},
          "score": {"type": "integer", "minimum": 0, "maximum": 20},
          "explanation": {"type": "string"}
        }
      }
    },
    "calibration_note": {"type": "string"},
    "total_score": {"type": "integer", "minimum": 0, "maximum": 100}
  }
}

📌 Seviye 4 — Araç Kullanımı (Tool Calling) ve İş Akışı (Workflow)

Temellendirme Başlıyor

Seviye 3'te rubriği örneklerle kalibre ettik; fakat değerlendirme hâlâ yalnızca LLM yorumuna dayanıyor. Şimdi dış sistemlerden gelen deterministik metrikleri kanıt olarak ekliyoruz.

Kullanılan Metrikler:

ROUGE-L F1: Kelime dizisi örtüşmesini ölçer.
Hafif Benzerlik Skoru: Token cosine + Token Jaccard + Karakter 3-gram cosine + Sequence ratio birleşimi.

Metrik Yorumlama Kuralları:

ROUGE-L F1 düşükse kelime örtüşmesinin düşük olduğunu gösterir; tek başına düşük anlamsal benzerlik kanıtı değildir.
Hafif Benzerlik Skoru ROUGE-L'ye göre daha yüksekse, metinler farklı kelimelerle benzer mesaj veriyor olabilir.
Hafif Benzerlik Skoru gerçek semantik embedding değildir; karar destek sinyali olarak kullanılmalı, tek karar verici yapılmamalıdır.

🌍 Gerçek Dünyada Neden Bu Kullanılır?

Güvenilirlik: ROUGE ve hafif benzerlik skorları deterministiktir — aynı metin çiftine her zaman aynı skorları verir.
İzlenebilirlik: LLM yorumu dış kanıta dayandığı için değerlendirme daha denetlenebilir olur.
Maliyet Kontrolü: Hafif metrikler hızlıdır ve ağır model bağımlılığı gerektirmez.

🔬 Deney Hijyeni Notu

Seviye 4, Seviye 3 ile aynı rubrik metnini kullanır. Bu bilinçli bir karar: iki seviye arasındaki fark rubrik değişikliği değil, yalnızca dış metrik bağlamıdır.

Seviye 4'te eklenen Zorunlu JSON alanları:

metric_interpretation: ROUGE-L F1 ve Hafif Benzerlik Skoru değerlerini nasıl yorumladığını açıkla.
calibration_note: Rubrik kalibrasyon örneklerinin puanlamanı nasıl etkilediğini açıkla.

Beklenen JSON şeması (Seviye 4):

{
  "type": "object",
  "required": ["evaluations", "metric_interpretation", "calibration_note", "total_score"],
  "properties": {
    "evaluations": { /* Seviye 3 ile aynı 5 öğeli liste */ },
    "metric_interpretation": {"type": "string"},
    "calibration_note": {"type": "string"},
    "total_score": {"type": "integer", "minimum": 0, "maximum": 100}
  }
}

📌 Seviye 5 — ReAct ve Ollama Tool Calling ile Gerçek Ajan Döngüsü

Gerçek Agentic Loop

Seviye 4'te güçlü bir iş akışı kurduk ama kurduğumuz sistem gerçek bir ajan mıydı? Tam olarak hayır. Çünkü metrikleri Python ile biz hesapladık. Gerçek ajan davranışında model hangi kanıta ihtiyaç duyduğunu belirler, yazılım katmanı aracı çalıştırır ve sonuç tekrar modele döner.

ReAct Döngüsü:

Reasoning (Muhakeme): Model hangi dış kanıta ihtiyaç duyduğunu belirler.
Action (Eylem): Model düz metin yazmak yerine Ollama'nın native tool_calls alanını üretir.
Observation (Gözlem): Python ilgili fonksiyonu çalıştırır, sonucu role="tool" olarak modele geri verir.
Final Answer (Nihai Cevap): Model tool sonuçlarını kullanarak rubrik temelli JSON değerlendirmesini üretir.

Ollama Native Tool Calling Akışı:

Fonksiyonlar `tools=[...]` listesiyle modele tanıtılır.
Model gerekiyorsa `response.message.tool_calls` üretir.
Python bu tool call'ları çalıştırır.
Sonuçlar `role="tool"` mesajları olarak konuşmaya eklenir.
Model tool sonuçlarına dayanarak nihai cevabı üretir.

Tool Tanımları (Python):

def calculate_rouge_tool(reference_text: str = "", candidate_text: str = "") -> str:
    """ROUGE skorlarını hesapla."""
    return json.dumps(calculate_rouge(METIN_1, METIN_2), ensure_ascii=False)

def calculate_lightweight_similarity_tool(reference_text: str = "", candidate_text: str = "") -> str:
    """Notebook'taki sabit Metin 1 ve Metin 2 için hafif benzerlik skorunu hesapla.
    
    Args:
        reference_text: Eğitim demosunda dikkate alınmaz; tool sabit METIN_1 kullanır.
        candidate_text: Eğitim demosunda dikkate alınmaz; tool sabit METIN_2 kullanır.
    
    Returns:
        Token cosine, token Jaccard, karakter 3-gram cosine, sequence ratio 
        ve birleşik skoru içeren JSON string.
    """
    return json.dumps(calculate_lightweight_similarity(METIN_1, METIN_2), ensure_ascii=False)

Tool Calling Loop (Pseudo-Python):

messages = [
    {"role": "system", "content": TOOL_CALLING_SYSTEM_PROMPT},
    {"role": "user", "content": "Metin 1: ..., Metin 2: ..."},
]

while True:
    response = client.chat(
        model=MODEL,
        messages=messages,
        tools=[calculate_rouge_tool, calculate_lightweight_similarity_tool],
    )
    messages.append(response.message)

    if not response.message.tool_calls:
        print(response.message.content)  # Final cevap
        break

    for tool_call in response.message.tool_calls:
        tool_name = tool_call.function.name
        result = available_tools[tool_name](**tool_call.function.arguments)
        messages.append({
            "role": "tool",
            "tool_name": tool_name,
            "content": str(result),
        })

Neden Bu Ustalık Sınıfıdır?

ReAct yalnızca Thought / Action / Observation yazdırmak değildir; düşünceyi gerçek araç yürütmeye bağlamaktır.
Ajan; prompt, tool calling, execution loop, grounding ve hata kontrolü katmanlarının birlikte tasarlanmasıdır.
Model araç ihtiyacını belirler, Python aracı gerçekten çalıştırır, nihai değerlendirme dış kanıtla desteklenir.

📊 Seviye 5 Token Maliyeti:

"Seviye 5 çok turlu (multi-turn) bir ajan loop'u olduğu için giriş tokenı (input token), yalnızca ilk kullanıcı promptunun uzunluğu değildir. Her client.chat çağrısında sistem mesajı, kullanıcı mesajı, önceki asistan mesajları ve tool sonuçları yeniden bağlama girer. Bu nedenle Seviye 5'teki input token toplamı, tekil token sayısı değil, kümülatif işlenen token / maliyet göstergesidir."

🛡️ Gerçek Dünyada: Üretim Ortamı Koruma Katmanları

Gerçek üretimde şu korumalar eklenir: şema doğrulama (schema validation), maksimum adım sayısı (max step limit), tool izin listesi (tool allowlist), yeniden deneme (retry) ve izleme/günlükleme (tracing/logging).

Seviye 5 Tool Calling JSON şeması:

{
  "type": "object",
  "required": ["evaluations", "metric_interpretation", "calibration_note", "total_score"],
  "properties": {
    "evaluations": {
      "type": "array",
      "minItems": 5,
      "maxItems": 5,
      "items": {
        "type": "object",
        "required": ["criterion", "score", "explanation"],
        "properties": {
          "criterion": {"type": "string"},
          "score": {"type": "integer", "minimum": 0, "maximum": 20},
          "explanation": {"type": "string"}
        }
      }
    },
    "metric_interpretation": {"type": "string"},
    "calibration_note": {"type": "string"},
    "total_score": {"type": "integer", "minimum": 0, "maximum": 100}
  }
}

📌 Seviye 6 — Rubrik Bazlı Sub-Agentlar ve Python Aggregator

Modüler Mimarisi

Seviye 5'te tek bir ajan hem araç çağırdı hem de bütün rubriği tek başına yorumladı. Bu seviyede farklı bir mimari deniyoruz: tek büyük prompt yerine, her rubrik kriterini ayrı bir alt ajana (sub-agent) veriyoruz.

Mimari:

1 generic sub-agent fonksiyonu yazılır.
Bu fonksiyon 5 farklı rubrik konfigürasyonu ile 5 kez çağrılır.
Her sub-agent yalnızca kendi kriterini değerlendirir.
Python aggregator sonuçları doğrular, sıraya koyar ve toplam skoru hesaplar.
Aggregator LLM çağrısı yapmaz — deterministiktir.

Bu Seviyenin Pedagojik Mesajı:

✅ "Her şeyi agent yapmayın!"
LLM yorumsal değerlendirme içindir. Python doğrulama, toplama, formatlama ve deterministik hesaplama içindir.

Sınırları:

5 sub-agent = 5 LLM çağrısı = Seviye 5'ten daha pahalı.
Her durumda gerekli değildir; rubrik büyüdüğünde veya denetlenebilirlik kritik olduğunda anlam kazanır.

Seviye 6 - Sub-Agent JSON Çıktısı (tek kriter için):

{
  "criterion": "Ana Fikir",
  "score": 18,
  "explanation": "Bu kritere özel değerlendirme",
  "evidence": "Metinden veya metriklerden dayanak"
}

Python Aggregator Toplam Çıktısı (tüm kriterler):

{
  "evaluations": [
    {"criterion": "Ana Fikir", "score": 18, "explanation": "...", "evidence": "..."},
    {"criterion": "Ton ve Üslup", "score": 16, "explanation": "...", "evidence": "..."},
    {"criterion": "Varlıklar", "score": 17, "explanation": "...", "evidence": "..."},
    {"criterion": "Eksik Bilgi", "score": 15, "explanation": "...", "evidence": "..."},
    {"criterion": "Akıcılık", "score": 14, "explanation": "...", "evidence": "..."}
  ],
  "metric_interpretation": "ROUGE ve hafif benzerlik metrikleri her sub-agent'a bağlam olarak verildi; her kriter kendi uzman alt ajanı tarafından yorumlandı.",
  "aggregation_note": "Toplam skor Python aggregator tarafından deterministik olarak hesaplandı; LLM orchestrator kullanılmadı.",
  "total_score": 80
}

Seviye 6 Python aggregator fonksiyon örneği:

def aggregate_sub_agent_results(sub_agent_results, metrics_context):
    expected_criteria = [config['criterion'] for config in RUBRIC_AGENT_CONFIGS]
    actual_criteria = [result['parsed'].get('criterion') for result in sub_agent_results]

    if actual_criteria != expected_criteria:
        raise ValueError(f"Sub-agent kriter sırası beklenenle aynı değil.")

    evaluations = []
    for result in sub_agent_results:
        parsed = result['parsed']
        score = parsed.get('score')
        if not isinstance(score, int) or not 0 <= score <= 20:
            raise ValueError(f"Geçersiz score: {parsed}")
        evaluations.append({
            'criterion': parsed['criterion'],
            'score': score,
            'explanation': parsed['explanation'],
            'evidence': parsed['evidence'],
        })

    total_score = sum(item['score'] for item in evaluations)
    return {
        'evaluations': evaluations,
        'metric_interpretation': '...',
        'aggregation_note': 'Toplam skor Python ile deterministik olarak hesaplandı.',
        'total_score': total_score,
    }

Seviye 6 — Token Maliyeti:

5 sub-agent = 5 bağımsız LLM çağrısı
Her çağrı sistem promptu + kullanıcı promptu + metrik bağlamını içerir
Toplam input token = 5 × (sistem + kullanıcı promptu uzunluğu)
Aggregator token maliyeti = 0 (Python kodu çalışır)

Seviye 6 — Sub-Agent JSON Şeması (build_sub_agent_system_prompt içinde):

{
  "type": "object",
  "required": ["criterion", "score", "explanation", "evidence"],
  "properties": {
    "criterion": {"type": "string"},
    "score": {"type": "integer", "minimum": 0, "maximum": 20},
    "explanation": {"type": "string"},
    "evidence": {"type": ["string", "array", "object"]}
  }
}

📌 Seviye 7 — Orkestratör Ajanlar ve Ne Zaman Gerekli Olmadıkları

Mimari Karar

Seviye 6'dan sonra doğal soru: "Bu alt ajanları bir de orkestratör ajan yönetse daha iyi olmaz mı?"

Orkestratör Ajan (Orchestrator Agent) gerçek hayatta güçlü bir mimaridir. Görevi parçalara ayırabilir, hangi sub-agent'ın çalışacağına karar verebilir, araç seçebilir, eksik veya çelişkili sonuçlarda yeniden deneme başlatabilir ve farklı ajanlardan gelen sonuçları nihai karara dönüştürebilir.

Ancak bu örnekte buna bilinçli olarak gerek duymuyoruz, çünkü:

5 rubrik kriteri önceden belli.
Her kriterin mutlaka çalışması gerekiyor.
Her sub-agent yalnızca kendi kriterini değerlendiriyor.
Eksik kriter kontrolü, sıralama ve toplam skor Python ile güvenilir biçimde yapılabiliyor.

🏗️ Orkestratör Ajan Ne Zaman Anlamlıdır?

Hangi sub-agent'ların çalışacağı görevden göreve değişiyorsa.
Araç seçimi, veri kaynağı seçimi veya iş akışı dallanması gerekiyorsa.
Alt ajan cevapları arasında çelişki varsa ve yorumlayıcı uzlaştırma gerekiyorsa.
Kalite kontrol, yeniden deneme, eksik bilgi tamamlama veya insan onayı gibi dinamik adımlar varsa.

Seviye 7'nin Mesajı: Orkestratör + sub-agent mimarileri vardır ve önemlidir; fakat her problemde gerekli değildir. Bu örnekte Python aggregator doğru, sade ve öğretici tercihtir.

💡 Seviye 7 Notu: Bu seviye yeni bir LLM çağrısı çalıştırmaz. Mimari karar verme ve sınır çizme bölümüdür. Performans grafikleri Seviye 0-6 deneylerinin maliyetini gösterir.

📊 Tüm Seviyelerin Karşılaştırması

Seviye	Yaklaşım	Eklenen Katman	Kazanım	Sınır / Ders
Lvl 0	Persona / Kara Kutu	Basit sistem promptu	Hızlı başlangıç	Tutarsız, açıklanamaz, halüsinasyona açık
Lvl 1	JSON + Açıklama	Yapılandırılmış çıktı	Cevap parse edilebilir	Hâlâ subjektif
Lvl 2	Rubrik	Kriter bazlı değerlendirme	Daha objektif skor	Dış kanıt yok, hâlâ LLM yorumu
Lvl 3	One-Shot / Few-Shot Kalibrasyon	Kriter bazlı örnekler	Tutarlı skorlar	İşlem tokenı artar
Lvl 4	Workflow + Tools	ROUGE + hafif benzerlik metrikleri	Grounded, kanıta dayalı	Tool seçimini yazılımcı yapar
Lvl 5	ReAct + Tool Calling	Otomatik tool çağrısı + execution loop	Gerçek agent davranışı	Yüksek maliyet, loop yönetimi gerekli
Lvl 6	Sub-Agentlar + Python Aggregator	Generic sub-agent + deterministic toplama	Görev ayrıştırma, sorumluluk ayrımı	5× LLM çağrısı, daha pahalı
Lvl 7	Orkestratör Ajan Kararı	Mimari karar verme	İleri mimari anlayışı	Her yerde orkestratör gerekmez

🎓 Son Mesaj: Prompt Mühendisliği, Sistem Mühendisliğine Dönüşür

Bir ajana yalnızca güçlü görünen bir prompt verip doğru çalışmasını beklemek yeterli değildir.
Gerçek Yapay Zeka Ajanı, yalnızca cevap üreten bir model değil; düşünme biçimi, araç kullanımı, muhakeme adımları ve veriye dayalı kanıtları birlikte yönetilen bir yazılım sistemidir.

Seviye 0'dan Seviye 7'ye ilerlerken aslında aynı fikri katman katman inşa ettik. Önce çıktıyı yapılandırdık, sonra değerlendirmeyi rubrikle parçaladık, ardından örneklerle kalibre ettik. Daha sonra metriklerle temellendirme ekledik ve ReAct fikrini gerçek araç yürütmeye bağladık. Sonunda orkestratör ajan gibi daha ileri mimarilerin var olduğunu, fakat bu örnekte ek LLM orchestrator kullanmamanın daha doğru mühendislik kararı olduğunu gördük.

Bir YZ Mühendisi olarak değerimiz burada ortaya çıkar: Modelden mucize beklemek yerine, modelin güçlü ve zayıf yönlerini anlayıp etrafına doğru mimariyi kurmak. İyi ajan tasarımı; prompt yazmak kadar, veriyle kanıtlama, araçlarla destekleme, muhakemeyi görünür kılma ve çıktıyı ölçülebilir hale getirme işidir.

📝 Eğitimde Kullanılan Test Metinleri

Bu iki metin özellikle seçilmiştir: kelime örtüşmesi düşük (düşük ROUGE), ancak anlamsal olarak benzer mesaj vermektedirler.

Metin 1 (Referans):
"Yapay zeka modellerinin eğitilmesi sürecinde, yüksek kaliteli veri setlerinin kullanılması kritik bir öneme sahiptir. Eğer veri seti hatalı, yanlı veya eksik bilgiler içeriyorsa, modelin üreteceği sonuçlar da kaçınılmaz olarak kusurlu ve güvenilmez olacaktır. Bu nedenle veri temizliği, model mimarisinin karmaşıklığından bile daha öncelikli bir adımdır."

Metin 2 (Sistemden Gelen Çıktı):
"Makine öğrenmesi algoritmalarının başarısı, büyük ölçüde beslendikleri bilginin kalitesine bağlıdır. Kirli, önyargılı ya da noksan verilerle beslenen algoritmalar, doğal olarak yanlış ve itimat edilemez çıktılar verecektir. Dolayısıyla, verilerin filtrelenmesi ve düzenlenmesi, sistemin altyapısını kurmaktan çok daha elzem bir süreçtir."

🏷️ Etiketler & Hashtagler

#YapayZeka #AI #MachineLearning #DeepLearning #LLM #LargeLanguageModel #PromptMühendisliği #PromptEngineering #AgentDesign #ArtificialIntelligence #Ollama #ToolCalling #ReAct #SubAgent #Orchestrator #StructuredOutput #Rubric #FewShot #Grounding #Explainability #RAG #ROUGE #TokenMaliyeti #MuratKarakayaAkademi #YZMühendisliği #YZ #AIEngineering #AIAgents #TechEducation #YouTubeEğitim #Blogger

How to Design Real AI Agents (Agents)

noreply@blogger.com (Murat Karakaya) — Thu, 18 Jun 2026 20:30:24 +0000

How to Design Real AI Agents (Agents) — A Step-by-Step Guide from Level 0 to Level 7

How to Design Real AI Agents (Agents)?

Transitioning from "Persona" to Tool-Using Decision Mechanisms
A step-by-step senior-level AI Engineer guide from Level 0 to Level 7.

Published: June 2026 | Reading time: ~25 min | Category: AI Engineering

🎯 Introduction: Why "You Are the Best AI Engineer in the World" Is Not Enough

90% of online tutorials tell you to write this to create an agent:

"You are the best software engineer in the world..."

If you are deploying an application to production, prompts written with only persona will turn your system into a hallucination bomb.

The real power of agents does not come from the roles you assign them; it comes from Tool Calling, Grounding, and Explainability.

💡 What Will You Learn in This Post?

In this post we will take a simple problem — "measuring text similarity" — and show you step by step how to evolve it from a novice approach to an autonomous level designed by a senior AI Engineer. At each level we will compare prompts, architecture, and cost.

🎬 Learn with Video: Murat Karakaya Akademi

You can also watch this training on the Murat Karakaya Akademi YouTube channel. Follow the same journey from Level 0 to Level 7 with step-by-step live demos, code explanations, and architectural analysis.

▶ Watch on YouTube — Murat Karakaya Akademi

📌 Level 0 — Novice Approach: Black Box & Hallucination

Beginner

Scenario: We need to find how similar Text 1 and Text 2 are on a 0–100 scale. (For example, in a RAG system, we measure how faithfully a generated answer stays true to the reference text).

Novice Prompt:
"You are a text analyst. Compare the given Text 1 and Text 2 and decide how similar they are. Return the similarity as a numeric value between 0–100. 0: They do not match at all, 100: They are completely identical word for word."

Why Is This Bad?

Black Box: The model only returns "75". Why 75? Not 74 or 80? We don't know.
Subjectivity: The same texts might get 60 one day and 85 the next.
Hallucination Risk: LLMs cannot perform mathematical measurements; they predict words. "75" is a fabricated (hallucinated) value.

📌 Level 1 — Structured Output & Chain of Thought

Improvement

The first thing we want is Explainability. We tell the model: "Don't just give me the result, show me your thinking process."

"You are a text analyst. Your goal is to measure the semantic similarity between two texts. Your output MUST be a valid JSON object. Do not use Markdown or additional text. Required JSON fields: - reasoning: The specific justification for similarity and differences between these two texts. - similarity_score: An integer between 0-100. Expected JSON schema: { "type": "object", "required": ["reasoning", "similarity_score"], "properties": { "reasoning": {"type": "string"}, "similarity_score": {"type": "integer", "minimum": 0, "maximum": 100} } }"

Why Is This Better?

Chain of Thought: We did not ask for the score first. We asked it to fill the reasoning field first. The model justifies its own inference while writing the explanation.
Debugging: If the score is 40, we can look at the logs and say "The model missed this detail, that's why it gave a low score."
Integration: The JSON output can be parsed by application code.

⚠️ What Is Missing: The score is still subjective. The 0–100 scale is too broad and unstructured for an LLM.

📌 Level 2 — Rubric and Objectivity (Divide & Conquer)

Increased Autonomy

We are not allowing the agent to interpret the abstract concept of "similarity" on its own. We give it rules (rubric). We break the problem into parts.

Rubric:

1. Main Idea (0-20): Do both texts convey the same core message?
2. Tone and Style (0-20): Do the texts have the same formality and emotion?
3. Entities (0-20): Do the names, dates, and numbers in the texts match?
4. Missing Information (0-20): Does Text 2 omit an important detail from Text 1?
5. Fluency (0-20): How structurally coherent is Text 2?

"You are an expert evaluator. Evaluate the two texts according to the 5 criteria below. Each criterion is scored 0-20. Your output MUST be a valid JSON object. Do not use Markdown or additional text. Required JSON fields: - evaluations: A list of 5 items [criterion, score, explanation] - total_score: The sum of the five criterion scores. Expected JSON schema: { "type": "object", "required": ["evaluations", "total_score"], "properties": { "evaluations": { "type": "array", "minItems": 5, "maxItems": 5, "items": { "type": "object", "required": ["criterion", "score", "explanation"], "properties": { "criterion": {"type": "string"}, "score": {"type": "integer", "minimum": 0, "maximum": 20}, "explanation": {"type": "string"} } } }, "total_score": {"type": "integer", "minimum": 0, "maximum": 100} } }"

Why Is This Better?

Grounding: We removed the model from abstract evaluation on a scale of 100.
Objectivity: Scores will be much more consistent even if you run them at different times (variance decreases).
Comparability: We can evaluate different prompts against the same rubric.

📌 Level 3 — Example-Based Rubric Calibration (One-Shot / Few-Shot)

Calibration

In Level 2 we gave the rubric; however, this was still zero-shot prompting. The model read the criteria but never saw from examples what "When do I give 20 points?", "What is the boundary case for 10?", "When is 0 appropriate?"

At this level we provide small, representative-examples for each criterion.

Scoring Calibration Examples:

Main Idea — 20 points: "Data cleaning is critical for model success" and "Model quality heavily depends on clean data" convey the same core message.
Main Idea — 10 points: Both texts discuss data quality but one focuses on security risks while the other focuses on model performance.
Main Idea — 0 points: One discusses data cleaning, the other discusses a sports match result.
Tone and Style — 20 points: Both texts are written in an academic and formal tone.
Tone and Style — 10 points: One is formal, the other more conversational, but the meaning is preserved.

Why Is This Better?

Consistency: The model uses the same score ranges more reliably.
Teachability: The rubric is now supported by behavioral examples, not just an abstract list.
Cost: Few-shot examples increase input tokens — so examples must be short and clear.

Expected JSON Schema:

{
  "type": "object",
  "required": ["evaluations", "calibration_note", "total_score"],
  "properties": {
    "evaluations": {
      "type": "array",
      "minItems": 5,
      "maxItems": 5,
      "items": {
        "type": "object",
        "required": ["criterion", "score", "explanation"],
        "properties": {
          "criterion": {"type": "string"},
          "score": {"type": "integer", "minimum": 0, "maximum": 20},
          "explanation": {"type": "string"}
        }
      }
    },
    "calibration_note": {"type": "string"},
    "total_score": {"type": "integer", "minimum": 0, "maximum": 100}
  }
}

📌 Level 4 — Tool Calling and Workflow

Grounding Begins

In Level 3 we calibrated the rubric with examples; however, the evaluation still relied solely on LLM interpretation. Now we add deterministic metrics from external systems as evidence.

Metrics Used:

ROUGE-L F1: Measures word-sequence overlap.
Lightweight Similarity Score: A combination of Token cosine + Token Jaccard + Character 3-gram cosine + Sequence ratio.

Metric Interpretation Rules:

If ROUGE-L F1 is low, this indicates low word-sequence overlap; it is not alone evidence of low semantic similarity.
If the Lightweight Similarity Score is higher than ROUGE-L, the texts may convey a similar message with different words.
The Lightweight Similarity Score is not a real semantic embedding; it should be used as a decision-support signal, not as the sole decision-maker.

🌍 Why Is This Used in the Real World?

Reliability: ROUGE and lightweight similarity scores are deterministic — they give the same scores to the same text pair every time.
Traceability: Since the LLM's opinion is grounded in external evidence, evaluation becomes more auditable.
Cost Control: Lightweight metrics are fast and do not require heavy model dependencies.

🔬 Experiment Hygiene Note

Level 4 uses the same rubric text as Level 3. This is a deliberate decision: the difference between the two levels is not a rubric change, but only external metric context.

Additional Required JSON Fields in Level 4:

metric_interpretation: Explain how you interpreted the ROUGE-L F1 and Lightweight Similarity Score values.
calibration_note: Explain how the rubric calibration examples affected your scoring.

Expected JSON Schema (Level 4):

{
  "type": "object",
  "required": ["evaluations", "metric_interpretation", "calibration_note", "total_score"],
  "properties": {
    "evaluations": { /* Same 5-item list as Level 3 */ },
    "metric_interpretation": {"type": "string"},
    "calibration_note": {"type": "string"},
    "total_score": {"type": "integer", "minimum": 0, "maximum": 100}
  }
}

📌 Level 5 — ReAct and Ollama Tool Calling with Real Agent Loop

Real Agentic Loop

We built a strong workflow in Level 4, but was our system a real agent? Not exactly. Because we calculated the metrics with Python. In real agent behavior, the model determines what evidence it needs, the software layer executes the tool, and the result returns to the model.

ReAct Loop:

Reasoning: The model determines what external evidence it needs to evaluate text similarity.
Action: Instead of writing plain text, the model produces Ollama's native tool_calls field.
Observation: Python executes the relevant function and returns the result to the model as role="tool".
Final Answer: The model uses the tool results to produce the rubric-based JSON evaluation.

Ollama Native Tool Calling Flow:

Functions are presented to the model via the `tools=[...]` list.
If needed, the model produces `response.message.tool_calls`.
Python executes these tool calls.
Results are added to the conversation as `role="tool"` messages.
The model produces the final answer based on tool results.

Tool Definitions (Python):

def calculate_rouge_tool(reference_text: str = "", candidate_text: str = "") -> str:
    """Calculate ROUGE scores."""
    return json.dumps(calculate_rouge(METIN_1, METIN_2), ensure_ascii=False)

def calculate_lightweight_similarity_tool(reference_text: str = "", candidate_text: str = "") -> str:
    """Calculate lightweight similarity score for the fixed Text 1 and Text 2 in the notebook.
    
    Args:
        reference_text: Not considered in training demo; tool uses fixed METIN_1.
        candidate_text: Not considered in training demo; tool uses fixed METIN_2.
    
    Returns:
        JSON string containing Token cosine, Token Jaccard, character 3-gram cosine, sequence ratio,
        and combined score.
    """
    return json.dumps(calculate_lightweight_similarity(METIN_1, METIN_2), ensure_ascii=False)

Tool Calling Loop (Pseudo-Python):

messages = [
    {"role": "system", "content": TOOL_CALLING_SYSTEM_PROMPT},
    {"role": "user", "content": "Text 1: ..., Text 2: ..."},
]

while True:
    response = client.chat(
        model=MODEL,
        messages=messages,
        tools=[calculate_rouge_tool, calculate_lightweight_similarity_tool],
    )
    messages.append(response.message)

    if not response.message.tool_calls:
        print(response.message.content)  # Final answer
        break

    for tool_call in response.message.tool_calls:
        tool_name = tool_call.function.name
        result = available_tools[tool_name](**tool_call.function.arguments)
        messages.append({
            "role": "tool",
            "tool_name": tool_name,
            "content": str(result),
        })

Why Is This a Mastery-Level Skill?

ReAct is not just writing Thought / Action / Observation; it is connecting thought to real tool execution.
An agent is the joint design of prompt, tool calling, execution loop, grounding, and error control layers.
The model determines tool needs, Python executes the tool, and the final evaluation is supported by external evidence.

📊 Level 5 Token Cost:

"Since Level 5 is a multi-turn agent loop, the input token is not just the length of the first user prompt. With each client.chat call, the system message, user message, previous assistant messages, and tool results are re-injected into context. Therefore, the input token total in Level 5 is not a unique token count, but a cumulative processed token / cost indicator."

🛡️ In the Real World: Production Guardrails

In real production, these protections are added: schema validation, maximum step limit, tool allowlist, retry, and tracing/logging.

Level 5 Tool Calling JSON Schema:

{
  "type": "object",
  "required": ["evaluations", "metric_interpretation", "calibration_note", "total_score"],
  "properties": {
    "evaluations": {
      "type": "array",
      "minItems": 5,
      "maxItems": 5,
      "items": {
        "type": "object",
        "required": ["criterion", "score", "explanation"],
        "properties": {
          "criterion": {"type": "string"},
          "score": {"type": "integer", "minimum": 0, "maximum": 20},
          "explanation": {"type": "string"}
        }
      }
    },
    "metric_interpretation": {"type": "string"},
    "calibration_note": {"type": "string"},
    "total_score": {"type": "integer", "minimum": 0, "maximum": 100}
  }
}

📌 Level 6 — Rubric-Based Sub-Agents and Python Aggregator

Modular Architecture

In Level 5, a single agent both called tools and interpreted the entire rubric on its own. At this level we try a different architecture: instead of one large prompt, we give each rubric criterion to a separate sub-agent.

Architecture:

1 generic sub-agent function is written.
This function is called 5 times with 5 different rubric configurations.
Each sub-agent evaluates only its own criterion.
Python aggregator validates, sorts, and calculates the total score.
The aggregator makes no LLM calls — it is deterministic.

The Pedagogical Message of This Level:

✅ "Don't make everything an agent!"
LLM is for subjective evaluation. Python is for validation, aggregation, formatting, and deterministic computation.

Limitations:

5 sub-agents = 5 LLM calls = more expensive than Level 5.
Not necessary in every case; it makes sense when the rubric grows or when audibility is critical.

Level 6 — Sub-Agent JSON Output (single criterion):

{
  "criterion": "Main Idea",
  "score": 18,
  "explanation": "Specific evaluation for this criterion",
  "evidence": "Basis from text or metrics"
}

Python Aggregator Total Output (all criteria):

{
  "evaluations": [
    {"criterion": "Main Idea", "score": 18, "explanation": "...", "evidence": "..."},
    {"criterion": "Tone and Style", "score": 16, "explanation": "...", "evidence": "..."},
    {"criterion": "Entities", "score": 17, "explanation": "...", "evidence": "..."},
    {"criterion": "Missing Information", "score": 15, "explanation": "...", "evidence": "..."},
    {"criterion": "Fluency", "score": 14, "explanation": "...", "evidence": "..."}
  ],
  "metric_interpretation": "ROUGE and lightweight similarity metrics were provided as context to each sub-agent; each criterion was interpreted by its own expert sub-agent.",
  "aggregation_note": "Total score was computed deterministically by the Python aggregator; no LLM orchestrator was used.",
  "total_score": 80
}

Level 6 Python Aggregator Function Example:

def aggregate_sub_agent_results(sub_agent_results, metrics_context):
    expected_criteria = [config['criterion'] for config in RUBRIC_AGENT_CONFIGS]
    actual_criteria = [result['parsed'].get('criterion') for result in sub_agent_results]

    if actual_criteria != expected_criteria:
        raise ValueError(f"Sub-agent criterion order does not match expected.")

    evaluations = []
    for result in sub_agent_results:
        parsed = result['parsed']
        score = parsed.get('score')
        if not isinstance(score, int) or not 0 <= score <= 20:
            raise ValueError(f"Invalid score: {parsed}")
        evaluations.append({
            'criterion': parsed['criterion'],
            'score': score,
            'explanation': parsed['explanation'],
            'evidence': parsed['evidence'],
        })

    total_score = sum(item['score'] for item in evaluations)
    return {
        'evaluations': evaluations,
        'metric_interpretation': '...',
        'aggregation_note': 'Total score was computed deterministically by Python.',
        'total_score': total_score,
    }

Level 6 — Token Cost:

5 sub-agents = 5 independent LLM calls
Each call includes system prompt + user prompt + metric context
Total input token = 5 × (system + user prompt length)
Aggregator token cost = 0 (Python code runs)

Level 6 — Sub-Agent JSON Schema (inside build_sub_agent_system_prompt):

{
  "type": "object",
  "required": ["criterion", "score", "explanation", "evidence"],
  "properties": {
    "criterion": {"type": "string"},
    "score": {"type": "integer", "minimum": 0, "maximum": 20},
    "explanation": {"type": "string"},
    "evidence": {"type": ["string", "array", "object"]}
  }
}

📌 Level 7 — Orchestrator Agents and When They Are Not Needed

Architectural Decision

After Level 6 the natural question is: "Wouldn't it be better if an orchestrator agent managed these sub-agents?"

Orchestrator Agent is a powerful architecture in the real world. An orchestrator can break down tasks, decide which sub-agent to run, select appropriate tools, initiate retries on missing or contradictory results, and convert results from different agents into a final decision.

However, in this example we deliberately do not need it, because:

The 5 rubric criteria are predetermined.
Every criterion must run.
Each sub-agent evaluates only its own criterion.
Missing criterion check, sorting, and total score can be reliably done with Python.

🏗️ When Does an Orchestrator Agent Make Sense?

When which sub-agents to run changes from task to task.
When tool selection, data source selection, or workflow branching is needed.
When there are contradictions between sub-agent responses and an interpretive reconciliation is needed.
When there are dynamic steps such as quality control, retry, missing information completion, or human approval.

Level 7's Message: Orchestrator + sub-agent architectures exist and are important; however, they are not necessary in every problem. In this example, the Python aggregator is the correct, simple, and instructive choice.

💡 Level 7 Note: This level does not make a new LLM call. It is an architectural decision-making and boundary-setting section. Performance graphs show the cost of Level 0-6 experiments.

📊 Comparison of All Levels

Level	Approach	Added Layer	Gain	Limitation / Lesson
Lvl 0	Persona / Black Box	Simple system prompt	Fast start	Inconsistent, unexplainable, hallucination-prone
Lvl 1	JSON + Explanation	Structured output	Answer becomes parseable	Still subjective
Lvl 2	Rubric	Criteria-based evaluation	More objective score	No external evidence, still LLM opinion
Lvl 3	One-Shot / Few-Shot Calibration	Criteria-based examples	More consistent scores	Input token cost increases
Lvl 4	Workflow + Tools	ROUGE + lightweight similarity metrics	Grounded, evidence-based	Developer selects the tools
Lvl 5	ReAct + Tool Calling	Automatic tool calling + execution loop	Real agent behavior	High cost, loop management needed
Lvl 6	Sub-Agents + Python Aggregator	Generic sub-agent + deterministic aggregation	Task decomposition, responsibility separation	5× LLM calls, more expensive
Lvl 7	Orchestrator Agent Decision	Architectural decision-making	Understanding of advanced architectures	Orchestrator not needed everywhere

🎓 Final Message: Prompt Engineering Becomes Systems Engineering

Simply giving an agent a powerful-sounding prompt and expecting it to work correctly is not enough.
A Real AI Agent is not just a model that produces answers; it is a software system that jointly manages thinking patterns, tool usage, reasoning steps, and data-driven evidence.

As we progressed from Level 0 to Level 7, we actually built the same idea layer by layer. First we structured the output, then we broke evaluation into rubric parts, then we calibrated with examples. Then we added grounding with metrics and connected the ReAct idea to real tool execution. Finally, we saw that more advanced architectures like orchestrator agents exist, but in this example, not adding an extra LLM orchestrator was the more correct engineering decision.

Our value as AI Engineers emerges here: instead of expecting miracles from the model, understand the model's strengths and weaknesses and build the right architecture around them. Good agent design is not just about writing prompts; it is about proving with data, supporting with tools, making reasoning visible, and making outputs measurable.

📝 Test Texts Used in the Training

These two texts were specifically selected: low word overlap (low ROUGE), yet they convey a semantically similar message.

Text 1 (Reference):
"In the process of training artificial intelligence models, the use of high-quality datasets is of critical importance. If the dataset contains incorrect, biased, or incomplete information, the results produced by the model will inevitably be flawed and unreliable. Therefore, data cleaning is a more prioritized step than the complexity of the model architecture."

Text 2 (System Output):
"The success of machine learning algorithms heavily depends on the quality of the information they are fed. Algorithms fed with dirty, biased, or incomplete data will naturally produce incorrect and untrustworthy outputs. Therefore, filtering and organizing data is a much more essential process than building the system's infrastructure."

🏷️ Tags & Hashtags

#ArtificialIntelligence #AI #MachineLearning #DeepLearning #LLM #LargeLanguageModel #PromptEngineering #AgentDesign #AI Agents #Ollama #ToolCalling #ReAct #SubAgent #Orchestrator #StructuredOutput #Rubric #FewShot #Grounding #Explainability #RAG #ROUGE #TokenCost #MuratKarakayaAkademi #AIEngineering #TechEducation #YouTubeEducation #Blogger

Are University Capstone Projects Still Necessary?

noreply@blogger.com (Murat Karakaya) — Fri, 12 Jun 2026 18:23:12 +0000

Are University Capstone Projects Still Necessary?

🎓 Are University Capstone Projects "Obsolete"? What Are We Really Grading?

🏛 In university engineering faculties, we are facing a staggering situation regarding "capstone projects"—often seen as the pinnacle of a student's educational life and where they are expected to put in serious effort for one or two semesters—that we can no longer ignore.

Engineering education, by its nature, aims to impart skills in problem-solving, analytical thinking, and designing a system from scratch. Traditionally, the capstone project is the ultimate test where a student puts all the theoretical knowledge acquired over 4 years into practice and proves they can stand on their own feet. I certainly exclude our students who focus on their projects ethically, with genuine hard work, turning night into day. However, the general landscape in the field and during jury defenses shows that we are frighteningly rapidly moving away from the core purpose of engineering education.

    The issue has now moved far beyond simply copying ready-made code snippets from StackOverflow or GitHub. The process now includes the unchecked use of artificial intelligence tools in a way that "adds zero vision and skill to the student."
  

The Next-Generation Landscape Juries Face

When you sit down to evaluate a project, the anatomy of the work presented to you now looks very similar. We can group the flaws of this new era under three main headings:

🤖 Frankenstein Projects

When you open the hood and look inside projects that seem highly complicated and appear to use modern architectures from the outside or on the presentation screen, you encounter utter chaos. In reality, there is no "engineering design"; you see that many ready-made infrastructures are somehow "stitched together" using Large Language Models (LLMs) or API requests. There is no logical coherence between code blocks. Systems that fully meet no technical requirements (performance, security, scalability) and run almost by pure luck are brought before the jury as a "success."

📄 Candidates Alien to Their Own Reports

In the past, even if projects were incomplete, the student knew where they made a mistake in the code they wrote or the circuit they built. Today, however, when we ask students about the most fundamental components of their project or their engineering choices at critical decision points, they cannot explain them. Questions like "Why did you choose this algorithm?" or "How will this database architecture handle this load?" remain unanswered. The saddest part is realizing they haven't even read or understood the statements, numbers, and tables in the brilliantly academic-sounding report (written by AI) they claim to have "prepared themselves."

🛟 Passing the Buck in Defenses

An engineer is someone who puts their signature under their work and takes responsibility. Yet, the answers we get to our questions during the jury usually point to a "third party": "It wrote it like this", "It gave these results", "When I fed the data to the system, it generated this graph". We frequently and sadly see that AI has ceased to be a "tool" that accelerates the learning process and has become a "subcontractor" onto which all cognitive action and responsibility are dumped.

We could multiply these examples for pages with anecdotes from the field. Artificial intelligence will not leave our lives; on the contrary, it will become even more integrated. Rejecting this is nothing more than Luddism. However, there are crucial questions that academia and the industry need to ask themselves and urgently open up for discussion.

❓️ The Big Questions

Under these circumstances, how realistic and useful to them is it to still give students 2 semesters of time for projects that an AI assistant can prototype in a few hours, and to take the resulting code seriously and grade it at the end of these processes?

Can our traditional evaluation methods (reading reports, listening to slide presentations) truly measure the student's engineering reflexes, problem-solving skills, and ethical understanding in an age where AI "solves" and perfectly packages everything?

If the professors on the jury are also using another AI to read the reports, at the end of the day, are we grading the student's capacity or the outputs of the AI model (ChatGPT, Claude, etc.) they used?

So what is the solution? How should we update this system? How can we transition to evaluating students as individuals who "design and manage systems" rather than just "writing code"?

We must approach this problem not with outdated rules like "ban artificial intelligence," but by completely changing our evaluation metrics. Perhaps capstone projects should no longer be months-long coding assignments; they should transform into System Design interviews where the candidate defends an architecture by drawing it on a board live in front of the jury and explains how they used AI "correctly and ethically."

I am very curious about the observations, experiences, and most importantly, the proposed solutions of my esteemed colleagues in academia and the industry regarding this issue. How do you think we will get out of this situation? Let's meet in the comments! 👇

#MuratKarakayaAkademi #Engineering #ArtificialIntelligence #Academia #Education #CapstoneProject #HigherEducation #EngineeringEthics #FutureEngineers

Üniversitelerde Bitirme Projelerine İhtiyaç Kaldı Mı?

noreply@blogger.com (Murat Karakaya) — Fri, 12 Jun 2026 16:54:54 +0000

Üniversitelerde Bitirme Projelerine İhtiyaç Kaldı Mı?

🎓 Üniversitelerde Bitirme Projelerine "İhtiyaç Kaldı Mı?" Gerçekten Neyi Puanlıyoruz?

🏛 Üniversitelerin mühendislik fakültelerinde, öğrencilerin eğitim hayatlarının zirvesi olarak görülen ve bir veya iki dönem boyunca ciddi bir emek vermesi beklenen "bitirme projelerinde" artık görmezden gelemeyeceğimiz, sarsıcı bir tabloyla karşı karşıyayız.

Mühendislik eğitimi, doğası gereği problem çözme, analitik düşünme ve sıfırdan bir sistem tasarlama yetilerini kazandırmayı hedefler. Geleneksel olarak bitirme projesi, öğrencinin 4 yıl boyunca edindiği tüm teorik bilgiyi pratiğe döktüğü, kendi ayakları üzerinde durduğunu kanıtladığı nihai bir sınavdır. Etiğiyle, alın teriyle projesine odaklanan, gecesini gündüzüne katan öğrencilerimizi elbette tenzih ediyorum. Ancak sahadaki ve jürilerdeki genel manzara, mühendislik eğitiminin temel amacından korkutucu bir hızla uzaklaştığımızı gösteriyor.

    Artık mesele sadece StackOverflow'dan veya GitHub'dan hazır kod parçacıkları kopyalamanın çok ötesine geçti. Sürece, yapay zeka araçlarının "öğrenciye hiçbir vizyon ve beceri kazandırmayan" o denetimsiz kullanımı dahil oldu.
  

Jürilerin Karşılaştığı Yeni Nesil Manzara

Bir projeyi değerlendirmek için masaya oturduğunuzda, karşınıza gelen çalışmaların anatomisi artık birbirine çok benziyor. Bu yeni dönemin defolarını üç ana başlık altında toplayabiliriz:

🤖 Frankenstein Projeler

Dışarıdan veya sunum ekranından bakıldığında son derece komplike, modern mimariler kullanılmış gibi görünen projelerin kaputunu açıp içine girdiğinizde tam bir kaosla karşılaşıyorsunuz. Aslında ortada bir "mühendislik tasarımı" yok; birçok hazır altyapının, Büyük Dil Modelleri (LLM) veya API istekleriyle birbirine "bir şekilde" teyellendiğini görüyorsunuz. Kod blokları arasında mantıksal bir bütünlük yok. Hiçbir teknik gereksinimi (performans, güvenlik, ölçeklenebilirlik) tam karşılamayan ve adeta şans eseri çalışan sistemler jürinin önüne "başarı" olarak getiriliyor.

📄 Kendi Raporuna Yabancı Adaylar

Eskiden projeler eksik çalışsa bile, öğrenci yazdığı kodun veya kurduğu devrenin neresinde hata yaptığını bilirdi. Bugün ise öğrencilere projenin en temel bileşenlerini veya kritik karar noktalarındaki mühendislik tercihlerini sorduğumuzda izah edemiyorlar. "Neden bu algoritmayı seçtin?" veya "Bu veri tabanı mimarisi bu yüke nasıl dayanacak?" soruları cevapsız kalıyor. İşin en acı tarafı, "biz hazırladık" dedikleri, muazzam bir akademik dille (Yapay Zeka tarafından) yazılmış rapordaki ifadeleri, rakamları ve tabloları kendilerinin dahi okumadığını, anlamadığını fark ediyoruz.

🛟 Faili Meçhul Savunmalar

Mühendis, yaptığı işin altına imzasını atan ve sorumluluk alan kişidir. Oysa jüride sorduğumuz sorulara aldığımız cevaplar genellikle "üçüncü bir şahsı" işaret ediyor: "Böyle yazdı", "Bu sonuçları verdi", "Sisteme veriyi verince bu grafiği çıkarttı". Yapay zekanın, öğrenme sürecini hızlandıran bir "araç" olmaktan çıkıp, tüm düşünsel eylemin ve sorumluluğun yıkıldığı bir "taşeron" haline geldiğini sıklıkla ve üzülerek görüyoruz.

Bütün bu örnekleri, sahadan anektodlarla sayfalarca artırabiliriz. Yapay zeka hayatımızdan çıkmayacak, aksine daha da entegre olacak. Bunu reddetmek ludditlikten öteye gitmez. Ancak akademinin ve sektörün kendisine dönüp sorması gereken, acilen tartışmaya açmamız gereken can alıcı sorular var.

❓️ Çılgın Sorular

Tüm bu şartlar altında, bir yapay zeka asistanının birkaç saat içinde prototipini çıkarabileceği projeler için öğrencilere hala 2 dönem zaman vermek ve bu süreçlerin sonunda ortaya çıkan kodu ciddiye alıp puanlamak ne kadar gerçekçi ve onlara ne kadar faydalı?

Geleneksel değerlendirme yöntemlerimiz (rapor okuma, slayt sunumu dinleme), yapay zekanın her şeyi "çözdüğü" ve mükemmel ambalajladığı bu çağda, gerçekten öğrencinin mühendislik refleksini, problem çözme becerisini ve etik anlayışını ölçebiliyor mu?

Eğer jürideki hocalar da raporları okumak için başka bir yapay zeka kullanıyorsa, günün sonunda biz öğrencinin kapasitesini mi yoksa kullandığı yapay zeka modelinin (ChatGPT, Claude vb.) çıktılarını mı notluyoruz?

Peki çözüm ne? Bu sistemi nasıl güncellemeliyiz? Öğrencileri "kod yazan" değil, "sistem tasarlayan ve yöneten" bireyler olarak değerlendirmeye nasıl geçebiliriz?

Artık "Yapay zeka yasaklansın" gibi çağ dışı kurallarla değil, değerlendirme metriklerimizi tamamen değiştirerek bu soruna yaklaşmalıyız. Belki de bitirme projeleri artık aylar süren kodlama ödevleri değil; adayın canlı yayında jüri karşısında bir mimariyi tahtaya çizerek savunduğu, yapay zekayı nasıl "doğru ve etik" kullandığını anlattığı Sistem Tasarımı (System Design) mülakatlarına dönüşmeli.

Akademideki değerli hocalarımın ve sektördeki meslektaşlarımın bu konudaki gözlemlerini, yaşadıkları olayları ve en önemlisi çözüm önerilerini çok merak ediyorum. Sizce bu işin içinden nasıl çıkacağız? Yorumlarda buluşalım! 👇

#MuratKarakayaAkademi #Mühendislik #YapayZeka #Akademi #Eğitim #BitirmeProjesi #YüksekÖğretim #MühendislikEtiği #GeleceğinMühendisleri

Gemini Free Tier LLM APIs for Developers

noreply@blogger.com (Murat Karakaya) — Mon, 04 May 2026 12:08:00 +0000

Technical Review & Strategy

Gemini LLM Free Tier for Developers: Limits and Application Architecture

Published by: Murat Karakaya Akademi • May 2026 • Read Time: 8 min

The biggest hurdle in developing AI applications is the high cost of APIs. Google's updated Gemini Free Tier, as of May 2026, offers revolutionary opportunities for engineers looking to overcome this barrier.

For a modern AI engineer, it's not just about the "intelligence" of a model; it's also about the technical skill of working efficiently within its usage constraints (Rate Limits). In this guide, we will analyze the capacities of free models and how to manage the limits that challenge these capacities with technical precision.

1. Model Segmentation and Use Cases

Model Group	Core Feature	Ideal Use Case
Gemini 3.1 Flash Lite	Low Latency	Fast chat interfaces and simple automations.
Gemini 2.5 Flash	High Logic	Code generation and complex data analysis.
Gemma 4 (26B/31B)	Open Architecture	Sensitive data and long document processing.
Gemini Embedding 2	Vector Space	Semantic search and RAG systems.

2. Key Rate Limit Concepts: RPM, TPM, and RPD

RPM (Requests Per Minute): The maximum number of calls you can make in a single minute.
TPM (Tokens Per Minute): The total volume of input and output processed per minute.
RPD (Requests Per Day): Your total daily usage quota.

3. Technical Parameters and Limit Analysis

Model Name	RPM	TPM	RPD
Gemini 3.1 Flash Lite	15	250K	500
Gemini 2.5 Flash	5	250K	20
Gemma 4 (All Versions)	15	Unlimited	1.5K
Gemini Embedding 2	100	30K	1K

💡 Strategic Recommendations for Architecture

Hybrid Model Usage: Gemini 2.5 Flash offers only 20 requests per day. Position this model as the "Chief Decision Maker" of your system. Delegate routine tasks like input validation or simple summarization to Flash Lite (500 RPD) to increase your daily capacity by 25 times.

The Gemma 4 Advantage: If your project involves analyzing massive text files, opting for the Gemma 4 series, which has no TPM limit, is the only way to avoid token overhead.

Conclusion: Limits Are Guides, Not Barriers

Building professional-grade pilot projects with free-tier models is entirely possible. With proper error handling and intelligent model selection, you can build a cost-effective AI infrastructure.

Learn API Integrations Through Practice

Learn how to manage Rate Limit errors at the code level and adapt them to real-world projects in our dedicated training series on the Murat Karakaya Akademi YouTube channel:

#MuratKarakayaAkademi #GeminiAI #LLM #Gemma4 #ArtificialIntelligence #MachineLearning #GoogleAI #RateLimits #AIEngineering #Python #FreeTier #GenerativeAI

Geliştiriciler İçin Gemini Ücretsiz (Free Tier) Dil Modelleri

noreply@blogger.com (Murat Karakaya) — Mon, 04 May 2026 12:05:00 +0000

Teknik İnceleme & Strateji

Geliştiriciler İçin Gemini Free Tier: Limitler ve Uygulama Mimarisi

Yayınlayan: Murat Karakaya Akademi • Mayıs 2026 • Okuma Süresi: 8 dk

Yapay zeka uygulamaları geliştirirken karşılaşılan en büyük engel, yüksek API maliyetleridir. Google'ın Mayıs 2026 itibarıyla güncellediği Gemini Ücretsiz Katmanı (Free Tier), bu bariyeri aşmak isteyen mühendisler için devrimsel olanaklar sunuyor.

Modern bir AI mühendisi için sadece modelin "zekası" değil, o modelin kullanım kısıtlamaları (Rate Limits) içinde nasıl verimli çalıştırılacağı da kritik bir beceridir. Bu rehberde, ücretsiz modellerin kapasitelerini ve bu kapasiteleri zorlayan limitlerin nasıl yönetileceğini teknik detaylarıyla inceliyoruz.

1. Model Segmentasyonu ve Kullanım Senaryoları

Model Grubu	Öne Çıkan Özellik	İdeal Kullanım Senaryosu
Gemini 3.1 Flash Lite	Düşük Gecikme	Hızlı chat arayüzleri ve basit otomasyonlar.
Gemini 2.5 Flash	Yüksek Mantık	Kod üretimi ve karmaşık veri analizi.
Gemma 4 (26B/31B)	Açık Mimari	Hassas veriler ve uzun döküman işleme.
Gemini Embedding 2	Vektör Uzayı	Semantik arama ve RAG sistemleri.

2. Rate Limit Kavramları: RPM, TPM ve RPD

RPM (Requests Per Minute): Bir dakika içinde yapılabilecek maksimum çağrı sayısı.
TPM (Tokens Per Minute): Dakikada işlenebilen toplam girdi ve çıktı hacmi.
RPD (Requests Per Day): Günlük toplam kullanım hakkı.

3. Teknik Parametreler ve Limit Analizi

Model Name	RPM	TPM	RPD
Gemini 3.1 Flash Lite	15	250K	500
Gemini 2.5 Flash	5	250K	20
Gemma 4 (Tüm Versiyonlar)	15	Sınırsız	1.5K
Gemini Embedding 2	100	30K	1K

💡 Uygulama Mimarisi İçin Stratejik Öneriler

Hibrit Model Kullanımı: Gemini 2.5 Flash günlük sadece 20 istek sunar. Bu modeli sistemin "ana karar vericisi" yapın. Girdi doğrulama ve basit özetleme gibi işleri 500 RPD sunan Flash Lite modeline devrederek günlük kapasitenizi 25 kat artırabilirsiniz.

Gemma 4 Avantajı: Eğer projeniz devasa metinleri analiz ediyorsa, TPM sınırı olmayan Gemma 4 serisini tercih etmek, token maliyetinden kaçınmanın tek yoludur.

Sonuç: Limitler Engel Değil, Kılavuzdur

Ücretsiz katman modelleriyle profesyonel seviyede pilot projeler üretmek tamamen mümkündür. Doğru hata yönetimi ve akıllı model seçimi ile maliyetsiz bir AI altyapısı kurabilirsiniz.

API Entegrasyonlarını Uygulamalı Öğrenin

Rate Limit hatalarının kod seviyesinde nasıl yönetildiğini ve gerçek dünya projelerine nasıl uyarlandığını Murat Karakaya Akademi YouTube kanalımızdaki özel eğitim serisinde bulabilirsiniz:

#MuratKarakayaAkademi #GeminiAI #LLM #Gemma4 #YapayZeka #MachineLearning #GoogleAI #RateLimits #AIEngineering #Python #FreeTier #GenerativeAI

Ollama Cloud ile Açık Kaynak Büyük Dil Modellerini (LLM) Bulutta Kullanmak

noreply@blogger.com (Murat Karakaya) — Thu, 05 Mar 2026 21:34:00 +0000

Ollama Cloud ile Açık Kaynak LLM'leri İndirmeden Denemek

Açık Kaynak büyük dil modelleri (LLM) dünyasında her gün yeni bir model ve yeni bir sürüm konuşuluyor. Bu çok iyi bir haber, çünkü artık "tek bir model"e mahkum değiliz. Ama pratikte çoğu kişi aynı iki probleme takılıyor: (1) Büyük modeller yerel GPU VRAM'ine sığmıyor, (2) Birden fazla modeli denemek için her seferinde devasa dosyalar indirmek, kurmak, silmek hem zaman hem de disk alanı tüketiyor. Kısacası, öğrenme ve deneme süreci daha en başta yorucu hale gelebiliyor.

Ben bu eğitimi tam da bu yüzden hazırladım: Açık Kaynak LLM'leri Bilgisayarınıza model dosyalarını indirip biriktirmeden de test edebilin. Üstelik sadece "çalıştırma" değil, doğru model seçimi ve uygulamaya entegrasyon mantığını da anlayın. Bu yazı, YouTube'daki eğitimimin blog formatında, ders notu kadar derinlemesine hazırlanmış versiyonu. Adım adım giderken, neden-sonuç ilişkisini de kurmaya çalışacağım.

Eğitim videosu (YouTube canlı yayın kaydı): https://youtube.com/live/QEZ8oF4A68k

Kodlar ve dokümanlar (GitHub deposu): https://github.com/kmkarakaya/OllamaCloud

Not: Bu yazıda mümkün oldukça Türkçe terimler kullanıyorum. Örneğin "Açık Kaynak" (open source), "bulut", "belirteç" (token), "akış" (stream) gibi. Kod ve komutlarda ise resmi isimler ve parametreler aynen kalıyor.

Bu Ders Notunu Nasıl Kullanmalısın?

Bu yazı iki tip okuyucu için tasarlandı:

LLM dünyasına yeni girenler: "Ben nereden başlayacağım, hangi kavramlar önemli?" diyenler.
Uygulama geliştirmek isteyenler: "Ben Python ile bir şey kurmak istiyorum, model denemeyi hızlı hale getirmek istiyorum." diyenler.

Benim önerim şu: Önce kavramları ve karar mantığını oku. Sonra CLI ile bir modeli çalıştır. Ardından API ve Python bölümüne geç. En sonda repodaki iki örneği (model karşılaştırma betiği ve Streamlit demo) çalıştırıp sonuçları yorumla. Bu sırayla ilerlersen, "ne yaptığını bilerek" ilerlemiş olursun.

Temel Kavramlar: Modeller Neden Ağır? (VRAM, RAM, Disk, belirteç)

Bir modelin "büyük" veya "ağır" olması tek bir şeye bağlı değil. Yeni başlayanların kafasını en çok karıştıran nokta da bu. Ben burada üç kaynak üzerinden anlatıyorum: Disk, RAM ve VRAM.

Disk: Model dosyalarını indirip sakladığın yer. Birkaç model denemek bile onlarca GB yapabilir.
RAM: CPU belleği. Bazı durumlarda (özellikle CPU ile çalışan senaryolarda) RAM sınırlayıcı olur.
VRAM: GPU belleği. Büyük modellerin yerelde hızlı çalışmasında çoğu zaman asıl sınırlayıcı kaynak budur.

Parametre sayısı arttıkça (örneğin 20B, 120B gibi) modelin kapasitesi artabilir, ama kaynak ihtiyacı da artar. Ancak tek mesele parametre sayısı değildir. Model çalışırken "KV cache" (kısaca bağlam belleği) de büyür. Bu cache, konuşma uzadıkça ve context window büyüdükçe artar. Bu yüzden "kısa bir soru" ile "uzun bir sohbet" aynı modelde farklı kaynak tüketimi üretebilir.

Bir diğer kritik kavram: belirteç. Modelin okuduğu ve ürettiği metin parçaları belirteçlere bölünür. Bir prompt ne kadar uzunsa, o kadar fazla belirteç işlenir. Bir konuşma geçmişi ne kadar uzunsa, modelin "tek seferde düşünmesi" için o kadar fazla belirteç taşınır. Bu hem süreyi (gecikme) hem de bellek ihtiyacını etkiler. Bu yüzden iyi bir pratik: Modeli değerlendirirken sadece tek bir prompt değil, farklı uzunluklarda promptlar denemek.

Peki quantization (kuantizasyon) ne işe yarar? Çok basit anlatayım: Modeli daha düşük hassasiyetle temsil ederek daha az bellek kullanmasını sağlar. Bu sayede bazı modeller yerelde çalışabilir hale gelir. Ama bazen kalite ve tutarlılık üzerinde etkisi olabilir. Bu nedenle model seçimi yaparken "en büyük model en iyisidir" gibi basit bir kural yok. Senin senaryon için "yeterince iyi + yeterince hızlı + yönetilebilir maliyet" dengesi önemlidir.

Bu noktada Ollama Cloud'un değeri ortaya çıkıyor: İndirme ve donanım bariyerini azaltıp, senin hızlıca öğrenme ve deneme yapmanı sağlıyor. Yani önce doğru modeli seçiyorsun, sonra yerel veya bulut stratejini buna göre planlıyorsun.

KV Cache ve Context Window: Uzun Sohbet Neden Yavaşlar?

Yeni başlayanların en sık yaşadığı sürprizlerden biri şudur: Aynı model, kısa bir promptta çok hızlı cevap verirken; konuşma uzadıkça veya tek prompt çok uzayınca bariz şekilde yavaşlar. Bunun temel nedeni "modelin geçmişi nasıl taşıdığı" ile ilgilidir. Dil modelleri, her yeni belirteç üretirken önceki belirteçlere dikkat (attention) mekanizmasıyla bakar. Konuşma uzadıkça bakması gereken içerik artar; bu da hesaplama maliyetini ve bellek ihtiyacını yükseltir.

Bu işin bellek tarafındaki adı çoğu yerde KV cache olarak geçer. Çok basit anlatımla: Model, önceki belirteçlere ait bazı ara temsil bilgilerini (key/value) cache'ler ve sonraki adımlarda bunları kullanır. Context window büyüdükçe bu cache de büyür. Yerelde GPU kullanıyorsan bu cache çoğu zaman VRAM'de tutulur ve VRAM'in sınırlıysa uzun konuşmalarda daha çabuk sınıra dayanırsın. bulut'da bu sınır sende görünmez ama performans etkisini yine hissedebilirsin.

Bu yüzden ben model denemesinde şunu özellikle öneriyorum: Sadece "tek cümlelik bir soru" ile karar verme. Aynı modelde kısa prompt, orta prompt ve uzun prompt dene. Bir de "konuşma geçmişi" senaryosu dene. Çünkü gerçek uygulamada çoğu zaman kullanıcı bir soru sorup çıkmıyor; takip sorusu soruyor, detay istiyor, format değiştiriyor. Modelin bu akıştaki davranışı, tek seferlik cevap kadar önemlidir.

Pratik bir performans ipucu: Uygulamada konuşma geçmişini sınırsız büyütme. Gerekirse eski mesajları özetle, kritik noktaları "memory" gibi tek bir mesajda taşı. RAG (retrieval-augmented generation) gibi teknikler de burada devreye girer: Her şeyi konuşma geçmişinde tutmak yerine, ilgili bilgiyi dışarıdan çekip prompta eklersin. Bu hem maliyeti hem de gecikmeyi yönetmeyi kolaylaştırır.

Ollama Cloud Nedir? (CLI ve API İki Yol)

Ollama Cloud, desteklenen modelleri bulut üzerinden çalıştırıp denemeni sağlayan bir altyapı. Senin tarafında iki "arayüz" var: Ollama CLI ve Ollama API. Benim ders notu yaklaşımımda bunlar iki farklı hedefe hizmet eder:

CLI yolu: Hızlı deneme ve hızlı kıyaslama. Prompt yaz, cevap al, model davranışını gör.
API yolu: Uygulama entegrasyonu. Python ile web app, bot, servis veya otomasyon kur.

Resmi dokümanlar (okurken açık dursun): https://docs.ollama.com/cloud, https://docs.ollama.com/api

Not: "Ücretsiz deneme" ve limitler dönemsel olarak değişebilir. En güncel bilgiyi resmi sayfalardan kontrol etmeni öneririm.

Ne Zaman bulut, Ne Zaman Yerel?

bulut ve yerel kullanım birbirinin alternatifi değil; çoğu zaman birbirini tamamlar. Ben pratikte şöyle karar veriyorum:

bulut-öncelikli: Model denemek, model seçmek, hızlı prototip yapmak, eğitim/demo üretmek.
Local-first: Offline çalışma, çok sık istek, veri politikası nedeniyle tamamen yerel zorunluluk.

Eğer amacın "hangi model işimi görür?" sorusunu cevaplamaksa bulut yaklaşımı büyük hız kazandırır. Modeli seçtikten sonra yerelde koşmak istiyorsan, o aşamada donanım yatırımı veya daha küçük/kuantize bir model seçimi mantıklı hale gelir. Yani benim için bulut çoğu zaman bir "hızlandırıcı katman".

Model Deneme ve Karşılaştırma İçin Basit Bir Rubrik

Model denemek demek, aynı soruyu üç modele sormak demek değildir. Gerçek bir karşılaştırma yapmak için küçük bir rubrik gerekir. Benim kullandığım basit rubrik şu başlıklardan oluşur:

Talimat takibi: "Şu formatta yaz" dediğimde uyuyor mu?
Tutarlılık: Aynı soruyu tekrar sorunca benzer kalite veriyor mu?
Yapı ve okunabilirlik: Cevap düzenli mi, maddeleme iyi mi?
Doğruluk: Bariz hatalar yapıyor mu, uydurma eğilimi var mı?
Hız: Aynı prompt için yanıt süresi kabul edilebilir mi?
Dil uyumu: Türkçe sorularda Türkçe kalitesi yeterli mi?

Bu rubriği kullanarak "model seçimi"ni hızlandırabilirsin. Örneğin eğitimde kullandığım yaklaşım: Aynı konuda 2-3 farklı prompt tipi hazırla, sonra her modeli bu prompt setiyle test et. Böylece tek bir cevaba göre karar vermezsin. Özellikle "format zorlayan" promptlar modelin talimat takibini çok net gösterir.

Bu rubriği repodaki compare_models.py ile otomatikleştirmeye başladık. betik mükemmel bir kıyaslama değil, ama doğru düşünme biçimini öğretir: Önce yapılandırılmış görevler, sonra gerçek çıktı incelemesi.

Prompt Tasarımı İpuçları: Modeli Doğru Sınamak

Bir modelin "iyi" veya "kötü" olduğuna karar vermek için önce doğru prompt yazmak gerekir. Çünkü LLM'ler, soruyu nasıl sorduğuna göre çok farklı davranabilir. Benim ders notu şeklinde önerdiğim basit yaklaşım: Promptu dört parçaya böl ve her parçayı net yaz.

Rol: Modelden nasıl davranmasını istiyorsun? (Örn: "Bir eğitmen gibi anlat.")
Hedef: Tam olarak ne istiyorsun? (Örn: "RAG'i 5 maddeyle açıkla.")
Kısıt: Uzunluk, dil, format, ton gibi sınırlar. (Örn: "Her madde 1 cümle olsun.")
Çıktı formatı: Madde madde mi, JSON mu, tablo mu? (Örn: "Başlık + maddeler.")

Karşılaştırma yaparken de aynı konsept geçerli: Aynı rubrikle ölçmek istiyorsan, modellerin hepsine aynı formatı zorlayan promptları ver. Örneğin Türkçe üreteceksen mutlaka Türkçe prompt seti hazırla. Kod yazdıracaksan "basit kod", "hata ayıklama", "refactor" gibi farklı kod görevleri ekle. Bu sayede tek bir promptta parlayan ama diğer görevlerde dağılan modelleri erken fark edersin.

Bir başka pratik ipucu: Deneme promptlarını "gerçek iş" promptlarından ayır. Deneme promptu daha kısa ve daha kontrollü olur; gerçek iş promptu ise daha karmaşık ve daha çok bağlam içerir. Bu yüzden karar verirken iki tür promptu da kullan. Deneme promptu ile ele, gerçek iş promptu ile doğrula.

Güvenlik ve İyi Pratikler: API Key ile Çalışmak

API key bir şifre gibi düşünülmeli. En sık yapılan hata, API key'i koda gömmek veya depo içinde paylaşmak. Benim önerim: API key'i bir ortam değişkeni olarak tanımla ve uygulamada oradan oku.

Resmi yetkilendirme dokümanı: https://docs.ollama.com/api/authentication

Windows PowerShell tarafında, geçerli oturum için örnek:

$env:OLLAMA_API_KEY = "your_api_key_here"

Bu şekilde key'i kaynak koduna yazmadan, hem CLI tarafında hem de Python tarafında kullanabilirsin. Eğitim içeriklerinde özellikle şunu vurguluyorum: Key yönetimi "küçük bir detay" değil; ileride üretim ortamına gittiğinde en kritik alışkanlıklardan biri olacak.

CLI ile Başlamak: İlk Deneme Akışı (Neden Bu Komutlar?)

Önce Ollama'nın Windows kurulumu gerekiyor. Resmi Windows kurulum sayfası: https://docs.ollama.com/windows

Kurulumdan sonra amaç şu: bulut tarafına giriş yap ve bir modeli terminalde çalıştır. Temel akış:

ollama --version
ollama signin
ollama run gpt-oss:120b-cloud

Burada ollama signin kritik. bulut erişimi gerektiren işlemlerde yerel CLI'nin kimlik doğrulamasını yapmış oluyorsun. Sonra ollama run ile modeli interaktif moda alıyorsun. Bu noktada önemli pratik: İlk denemelerde kısa promptlarla başla, sonra uzun promptlara geç. Çünkü uzun prompt, hem hız hem de bağlam yönetimi açısından modeli daha fazla zorlar.

Bir diğer önemli not: bulut model isimleri CLI tarafında bazen -cloud ekiyle gelir. API tarafında ise model adları farklı görünebilir. Bu yüzden ben API entegrasyonlarında "model adını hardcode etme" alışkanlığını bırakmanı öneriyorum. Bunun çözümü bir sonraki bölümde: /api/tags.

Direkt API Yolu: /api/tags ile Model Keşfi, /api/sohbet ile Cevap

Uygulama geliştireceksen API tarafı kritik. Ben burada iki endpointi "temel taş" gibi görüyorum:

/api/tags: Hangi modeller erişilebilir? Bu sorunun cevabı.
/api/sohbet: Mesaj gönderip cevap almak.

Endpoint dokümanları: https://docs.ollama.com/api/tags, https://docs.ollama.com/api/chat

Benim pratik yaklaşımım: Model adını "varsayma". Önce /api/tags ile listeyi çek, sonra uygulamanda o listeden seçim yaptır. Bu sayede bir model erişilebilir değilse uygulama kırılmaz; sadece seçeneklerde görünmez.

Minimal bir curl örneği (PowerShell'de):

curl __URL_16__ `
  -H "Authorization: Bearer $env:OLLAMA_API_KEY"

sohbet tarafında stream parametresi önemli bir kavram. stream=false dersen tek seferde cevap alırsın. stream=true dersen cevap parça parça gelir. Web uygulamalarında akış kullanıcı deneyimini iyileştirir, ama kodu biraz daha dikkatli yazmayı gerektirir. Eğitimde ben önce stream=false ile mantığı kurup, sonra akışa geçmeni öneriyorum.

Python ile Entegrasyon: Mantığı Bir Kez Kur, Her Yerde Kullan

Python tarafında benim önerim şu: Önce en küçük "çalışıyor mu?" prototipini kur. Sonra aynı mantığı web uygulamasına taşı. Ollama Cloud Python dokümanı burada: https://docs.ollama.com/cloud#python

Kullandığımız Python paketi: https://github.com/ollama/ollama-python

Python tarafında temel fikir:

İstemciyi host="__URL_21__" ile bulut'a yönlendir
Header'a Authorization: Bearer ... koy
chat() çağrısında model ve mesajları gönder

Minimal örnek:

import os
from ollama import Client

client = Client(
    host="__URL_22__",
    headers={"Authorization": f"Bearer {os.environ['OLLAMA_API_KEY']}"},
)

resp = client.chat(
    model="gpt-oss:120b",
    messages=[{"role": "user", "content": "RAG nedir? 5 maddeyle anlat."}],
    stream=False,
)

print(resp["message"]["content"])

Burada mesaj formatı çok önemli. Mesajlar bir liste ve her mesajın role alanı var (örneğin user). Gerçek uygulamada konuşma geçmişi tutarsın: Önceki mesajları da yeni promptla birlikte gönderirsin. Bu sayede model bağlamı "hatırlar". Ama şu riski unutma: Konuşma geçmişi uzadıkça belirteç sayısı artar; bu da gecikmeyi artırabilir. Bu yüzden pratik bir yöntem: Geçmişi sınırlamak veya kritik noktaları özetleyip "memory" gibi göndermek.

Hata senaryolarını ders notu gibi düşünelim:

401 Unauthorized: API key yanlış veya header formatı hatalı. İlk kontrol: ortam değişkeni + auth dokümanı.
404 / model not found: Model adı erişilebilir değil; önce /api/tags ile listeyi kontrol et.
Timeout/slow: Çok büyük model veya yoğunluk; daha küçük modelle dene, istekleri azalt, akış kullan.

Bu üç hata tipi, pratikte en sık görülenler. Eğitimde de özellikle "önce tags, sonra sohbet" mantığını vurguluyorum.

depo Walkthrough: İki Bağımsız Örnekle Öğrenmeyi Hızlandırmak

Eğitimi izleyip "tamam anladım" demek kolay. Asıl değer, iki örneği çalıştırıp sonuçları yorumlamakta. depo içinde üç kritik dosya var: requirements.txt, compare_models.py, app.py. Bu üçü birlikte "deneme -> karşılaştırma -> demo" akışını tamamlıyor.

Önce bağımlılıkları kurmak ve örnekleri çalıştırmak için pratik komutlar:

pip install -r requirements.txt
python compare_models.py
streamlit run app.py

Şimdi iki örneği tek tek ders notu gibi inceleyelim.

compare_models.py ne yapıyor? Bu betik "model seçimi" problemine pratik bir yaklaşım getiriyor. İçindeki iki yapı çok önemli:

MODELS: Karşılaştırılacak model listesi (ör. gpt-oss:20b, gpt-oss:120b, qwen3-coder:480b)
TASKS: Modelin cevap vermesini istediğin yapılandırılmış görevler

Scriptin yaklaşımı şu: Her modele aynı görevleri sorar, yanıt süresini ölçer ve basit bir kalite skoru çıkarır. Bu skor bir hakem değil; bir "erken sinyal". Skorun mantığı dosyada açık:

Anahtar kelime kapsama skoru (0-60): Görev için kritik kelimeleri geçiriyor mu?
Format skoru (0-40): Maddeleme var mı, satır sayısı makul mü, yanıt uzunluğu yeterli mi?

Skorun amacı şu: Hızlıca "bu model talimatları takip ediyor mu?" sorusuna yaklaşmak. Ama karar verirken mutlaka raporu okuyacaksın. betik, tüm çıktıları model_comparison_report.md dosyasına yazar. Bu dosyayı açıp yanıtları yan yana okumak, gerçek kalite farkını görmenin en iyi yoludur.

Bu betiği kendi senaryona uyarlamak için pratik öneriler:

Kendi işine uygun 3-5 görev ekle (Türkçe özetleme, kod üretimi, e-posta yazma, hata ayıklama vb.).
MODELS listesini /api/tags ile gördüğün erişilebilir modellere göre güncelle.
Skorun "tek ölçüt" olmadığını unutma; raporu mutlaka oku.

Şimdi ikinci örnek: app.py. Bu dosya Streamlit ile basit bir web arayüzü kuruyor. Bu demo, özellikle öğrenme ve manuel test için çok değerli. Çünkü CLI'de hızlı denersin ama bazen promptları düzenlemek, farklı formatları denemek, çıktıyı kopyalayıp incelemek tarayıcıda daha rahattır.

Uygulamanın akışı:

API key'i ortamdan alır veya kullanıcıdan ister.
bulut'dan model listesini çeker ve seçim sunar.
Prompt gönderilir, cevap ekranda gösterilir.

Bu yapının asıl öğretici tarafı şudur: Modeli "hardcode" etmek yerine listeden seçtirmek. Böylece erişilebilir modeller değişse bile uygulama dayanıklı olur. Bu, üretim sistemlerinde de çok işe yarayan bir alışkanlıktır.

Uygulamayı geliştirmek istersen, başlangıç için birkaç fikir:

Konuşma geçmişi (sohbet geçmişi) ekle: Önceki mesajları saklayıp tekrar gönder.
akış yanıt ekle: Cevap yazılıyor gibi görünsün.
Prompt şablonları ekle: "özetle / maddele / kod yaz" gibi hazır butonlar.
Çıktıyı kaydet: Prompt ve cevapları logla, sonra analiz et.

Sık Yapılan Hatalar ve Pratik Çözümler

Bu bölüm gerçek hayatın özeti: Hata alırsın ve çözersin. Ben en sık şunları görüyorum:

401 Unauthorized: API key yok, yanlış veya header formatı hatalı. Önce Authentication dokümanına bak, sonra ortam değişkenini kontrol et.
Model bulunamadı: Model adı erişilebilir değil. İlk adım: /api/tags ile modelleri listele ve doğru adı seç.
Çok yavaş yanıt: Büyük model veya yoğunluk olabilir. Daha küçük model dene, promptu kısalt, akış kullanmayı düşün.
Virtualenv karışıklığı: Farklı Python ortamına kurulum yapılıyor. En temiz yöntem: venv aç, sonra pip install -r requirements.txt.
Türkçe karakterler bozuk görünüyor: Kopyalama yaparken HTML editör modu dışında yapıştırmış olabilirsin. Blogger'da HTML görünümünde yapıştırmak genelde en sorunsuz yoldur.

Bu hataların ortak mesajı şu: Önce bağlantı ve yetkiyi doğrula, sonra model listesini doğrula, en son uygulama kodunu kurcala. Bu sırayla ilerlemek zamandan tasarruf ettirir.

Sık Sorulan Sorular (SSS)

Bu eğitimden sonra en çok gelen soruları kısa ve net cevaplayayım. Buradaki amaç "ezber" değil; doğru kontrol noktalarını öğretmek.

Ollama Cloud ücretsiz mi? Çoğu kişi bulutu "hızlı deneme" için kullanıyor. Ancak limit/politikalar zaman içinde değişebilir. En güncel bilgi için bulut sayfasını kontrol et.
Hangi modeller var, hangisini seçmeliyim? "Şu model kesin var" diye varsayma. Önce /api/tags ile listeyi gör. Seçimi rubrikle yap: talimat takibi, tutarlılık, hız, Türkçe kalitesi ve senin senaryona uygunluk.
CLI'de -bulut var ama API'de yok, neden? CLI ve API tarafında isimlendirme farklı görünebilir. Uygulama tarafında modeli listeden seçtirmen bu sorunu pratikte çözer.
ollama signin ile API key aynı şey mi? Hayır. ollama signin daha çok CLI akışı için oturum açma mantığıdır. API tarafında ise genelde API key + Bearer header ile çalışırsın. Detay için Authentication sayfasına bak.
Veri gizliliği açısından neye dikkat etmeliyim? Kural basit: Hassas veriyi göndermeden önce mutlaka politika/şartları oku ve kurumunun kurallarına göre hareket et. Eğitim ve demo sırasında gerçek müşteri verisi yerine sentetik/anonim veri kullanmak iyi bir alışkanlıktır.
Türkçe karakterler bozuk görünürse? Genelde iki sebep olur: dosya encoding'i veya Blogger'a yapıştırma modu. Bu dosya UTF-8 olarak hazırlanmıştır. Blogger'da HTML modunda yapıştırmak çoğu zaman sorunu çözer.

Mini Çalışma: Kendi Deneme Setini Oluştur

Bu yazıyı gerçekten değerli kılmak için sana küçük bir "ödev" seti bırakmak istiyorum. Eğer bir modeli seçmek istiyorsan, şu üç tip prompt hazırla:

Format testi: "5 maddeyle anlat, her madde 1 cümle olsun" gibi.
Akıl yürütme testi: "Adım adım açıkla" gibi.
Senaryo testi: "Benim işim şu, bana bir taslak çıkar" gibi.

Sonra aynı üç promptu üç farklı modelde dene. Karşılaştırma yaparken sadece "doğru mu?" diye bakma; rubriğe geri dön: Talimat takibi, tutarlılık, okunabilirlik ve hız. Bu küçük alışkanlık, öğrenme sürecini hızlandırır ve model seçimini daha sağlam yapar.

Benim Önerdiğim Deneme Stratejisi

Eğer bir proje için model seçeceksem ben genelde şu akışla ilerliyorum:

Önce 2-3 aday model belirlerim (biri hızlı/küçük, biri büyük/kaliteli, biri kod odaklı vb.).
compare_models.py ile hızlı karşılaştırma yaparım.
Rapor dosyasından cevapları okur, talimat takibi ve tutarlılığa bakarım.
Seçtiğim 1-2 modeli app.py ile manuel prompt testine sokarım.
Sonra uygulama entegrasyonuna geçerim (Python client ile).

Bu akışın güzelliği şu: Model seçimi "hissiyat" değil, kısa ama sistematik bir deneme sürecine dayanıyor. Üstelik bunu donanım yatırımı yapmadan başlatabiliyorsun.

Videoyu ve Kodları Burada Bulabilirsin

YouTube eğitim kaydı: https://youtube.com/live/QEZ8oF4A68k

GitHub deposu (README ve örnek kodlar): https://github.com/kmkarakaya/OllamaCloud

Resmi kaynaklar:

Kapanış

Ben bu eğitimi, "donanımım yetmiyor" bahanesinin seni açık kaynak LLM denemekten uzaklaştırmaması için hazırladım. Ollama Cloud ile hem farklı modelleri hızlıca deneyebilir, hem de seçtiğin modeli Python tarafında gerçek bir uygulamaya bağlayabilirsin.

Eğer sen de açık kaynak LLM'leri hızlıca denemek, karşılaştırma yapmak ve pratik bir akış kurmak istiyorsan videoyu izle, depo içindeki örnekleri çalıştır, sonra kendi senaryona uyarlayıp geliştirmeye başla. Benzer içerikler için Murat Karakaya Akademi'yi takip etmeyi unutma.

OpenClaw (Clawdbot) Rehberi: AI Agent Dünyasında Devrim mi, Hayal Kırıklığı mı?

noreply@blogger.com (Murat Karakaya) — Sat, 31 Jan 2026 21:03:00 +0000

OpenClaw (Clawdbot) Teknik İncelemesi: AI Agent Teknolojisinde İlk İzlenimler ve Risk Analizi

Değerli meslektaşlarım ve teknoloji meraklıları, bugün yapay zeka dünyasını kasıp kavuran, ancak arkasında büyük soru işaretleri barındıran OpenClaw (eski adıyla Clawdbot) projesini masaya yatırıyoruz. Bir akademisyen ve yazılım mimarı olarak, bu aracı 4 gün boyunca en derin teknik katmanlarına kadar test ettim. Sonuç; büyük bir potansiyel ama beraberinde getirdiği ciddi bir kaos.

Bu konuyu uygulamalı analizlerim ve kod yapısı üzerine düşüncelerimle birlikte takip etmek isterseniz videom size rehberlik edecektir:

Bu Eğitimde Neler Öğreneceksiniz?

Yapay Zeka İş Göreni (Agent) Kavramı: OpenClaw'un mimari yapısı ve vaatleri.
Kurulum Kabusu: Windows, WSL ve Mac arasındaki uyumsuzlukların teknik nedenleri.
Yetenekler (Capabilities) ve Bundle Yapısı: CLI araçlarının entegrasyonu.
Güvenlik ve Gizlilik Analizi: Headless browser ve hesap kapanma riskleri.
Gelecek Projeksiyonu: Projenin ticari akıbeti ve alternatifler.

1. OpenClaw Nedir? Bir "Kişisel Projenin" Anatomisi

OpenClaw, temelinde yerel makinenizde çalışan bir agent mimarisidir. Geliştiricisi, Github üzerinde 40'tan fazla kütüphaneyi bir araya getirerek, bilgisayarınızdaki işletim sistemi komutlarını, dosyaları ve harici servisleri yönetebilen bir yapı kurgulamış. Ancak dikkat edilmesi gereken nokta şudur: Bu bir ticari ürün değil, 3-4 günlük bir "kişisel proje" olarak meşhur oldu. Bu durum, dokümantasyondan tutun da kod stabilitesine kadar her noktada kendini hissettiriyor.

2. Tecrübeler ve Kurulum Zorlukları: 4 Günlük Kayıp mı?

Birçok Youtuber'ın "tek tıkla kurun" söylemlerinin aksine, teknik gerçeklik oldukça farklı. Yazılımın mimarisi neredeyse tamamen macOS ekosistemi düşünülerek kurgulanmış.

Windows Bariyeri: Doğrudan Windows üzerine kurulum yapmaya çalıştığınızda, bağımlılıklar ve yol tanımları (path) sebebiyle iki günüm sadece hataları çözmekle geçti.
WSL (Linux) Çıkmazı: Windows Subsystem for Linux (WSL) kullanımı bir çözüm gibi görünse de, OpenClaw'un "yeteneği" olan donanım erişimlerinde ve CLI bağlamlarında sistem kararsızlaşıyor.
Bundle Sorunları: Ana yazılımı kurmak kolay, ancak asıl güç olan "bundle" (yetenek paketleri) kısımları Windows'ta %99 oranında çalışmıyor.

3. Yetenekler ve CLI Entegrasyonu (Capabilities)

OpenClaw'u meşhur yapan asıl unsur, sadece sohbet etmesi değil, aksiyon almasıdır. Geliştirici, Google Docs, Gmail ve Drive gibi araçlara erişmek için özel CLI (GOG CLI) araçları yazmış. Yapay Zeka İş Göreni (Agent), bir işi yapması gerektiğinde CLI üzerinden komutlar üreterek sizin yerinize işlem yapar. Ancak bu süreçte dökümantasyon o kadar hızlı değişiyor ki, komut isimleri bile birbirine karışmış durumda.

# Kurulum ve Gateway başlama süreçlerinde isim değişikliklerine dikkat!

Eski komutlar: claudebot gateway

Yeni muhtemel yapı: openclaw launch

Not: Eğer Windows kullanıyorsanız stabilite sorunlarına hazırlıklı olun.

4. Kritik Riskler: Güvenlik ve Hesap Kapanmaları

Burada en ciddi uyarıyı yapmam gerekiyor. OpenClaw kullanımı iki ana risk barındırıyor:

Gizlilik Riski: Yazılım lokalde çalışsa da, modeller (GPT-4, Claude vb.) bulut tabanlıdır. Dokümanlarınızı okuttuğunuzda verileriniz dışarı çıkar. Ollama ile %100 lokal çözüm mümkün olsa da muazzam bir GPU gücü gerektirir.
Sosyal Medya Ban Riski: Araç, Instagram veya X gibi platformlara "headless browser" üzerinden bağlanıyor. Sosyal medya platformları bot kullanımını yasaklar. OpenClaw'un bu kullanımı tespit edilebilir ve hesaplarınızın kalıcı olarak kapanmasına neden olabilir.

5. Gelecek Beklentileri: Bu Yol Nereye Gider?

OpenClaw şu an bir "hype" dalgasının üzerinde. Ancak bu mimarinin geleceği çok açık:

Kurumsallaşma: Muhtemelen büyük bir teknoloji devi (Google veya OpenAI) bu projeyi veya benzerlerini satın alıp daha güvenli/ücretli bir modele dönüştürecektir.
Alternatiflerin Doğuşu: 3-4 ay içerisinde daha stabil, Windows dostu ve dökümante edilmiş alternatiflerin çıkması kaçınılmazdır.

Sıkça Sorulan Sorular (SSS)

1. Windows'ta denemeli miyim? Şu anki haliyle hayır. Eğer ileri düzey bir sistem yöneticisi değilseniz, harcayacağınız zaman alacağınız verimden çok daha fazla olacaktır.

2. OpenClaw güvenli mi? Açık kaynak kodlu olması bir avantaj ancak tek bir kişinin kontrolünde olan ve API yetkilerinizi verdiğiniz her araç gibi risk taşır. Özellikle sosyal medya entegrasyonlarından kaçınmalısınız.

3. Mac kullanıcıları neden daha avantajlı? Geliştirici kendi iş akışını Mac üzerinde kurguladığı için tüm testler ve kütüphane yolları bu işletim sistemine göre optimize edilmiş durumdadır.

Sonuç

OpenClaw, yapay zekanın sadece bir "sohbet botu" olmaktan çıkıp "iş yapan bir asistan" olma yolundaki önemli ama sancılı bir adımıdır. Teknik eksikliklerine rağmen bu heyecan verici alanı takip etmeye devam edeceğiz. Ancak şu an için "erken erişimdeki" bir oyun gibi düşünün; hatalar çok, stabilite az.

Daha Fazlasını Keşfedin: Yapay zeka ve yazılım mimarisi dünyasındaki derinlemesine analizleri kaçırmamak için Murat Karakaya Akademi YouTube kanalına abone olun. Kanalı Ziyaret Et & Abone Ol 🚀

#MuratKarakayaAkademi #OpenClaw #Clawdbot #AI #DeepLearning #SoftwareArchitecture #YapayZeka

LLAMA 3 ve Unsloth ile Adım Adım Fine-Tuning Rehberi

noreply@blogger.com (Murat Karakaya) — Thu, 22 Jan 2026 13:03:00 +0000

LLAMA 3 ve Unsloth ile Nutuk Eğitimi: Adım Adım Fine-Tuning Rehberi

Merhabalar arkadaşlar, Murat Karakaya Akademi YouTube kanalına hoş geldiniz. Bugün, daha önce başladığımız "İnce Ayar (Fine-Tuning)" eğitim serimizin en kritik aşamalarından birini gerçekleştireceğiz. 8 milyar parametreli devasa bir dil modeli olan LLAMA 3'ü, kendi hazırladığımız Nutuk veri setiyle nasıl eğitebileceğimizi ve ona Atatürk'ün ölümsüz eseri hakkında nasıl uzmanlık kazandırabileceğimizi göreceğiz.

Bu eğitimde sadece kod yazmayacağız; arkadaki matematiksel hileyi (LoRA), bellek optimizasyonunu ve modelin neden Unsloth kütüphanesiyle 2 kat daha hızlı eğitildiğini derinlemesine inceleyeceğiz. Hazırsanız, yapay zekanın "ince ayar" dünyasına giriş yapalım.

Bu konuyu uygulamalı olarak görmek ve kodları adım adım takip etmek için videoyu izlemenizi öneririm:

Bu Eğitimde Neler Öğreneceksiniz?

PEFT ve LoRA Kavramları: Milyarlarca parametreyi eğitmek yerine neden küçük "adaptörler" kullanıyoruz?
Unsloth Kütüphanesi: Bellek dostu ve yüksek performanslı Fine-Tuning nasıl yapılır?
Veri Hazırlığı: Nutuk metinlerini ShareGPT formatına ve modelin anlayacağı "Instruction" yapısına dönüştürme.
QLoRA (4-bit Quantization): T4 gibi ücretsiz GPU'larda dev modelleri eğitmenin sırrı.
Model Yayını: Eğitilen modeli Hugging Face'e yükleme ve tekrar geri çağırma.

Fine-Tuning'in Arkasındaki "Sihir": LoRA ve Düşük Dereceli Matrisler

Normalde 8 milyar parametreli bir modeli baştan aşağı eğitmek (Full Fine-Tuning) devasa sunucu parkları gerektirir. Ancak biz LoRA (Low-Rank Adaptation) yöntemini kullanıyoruz. Peki bu nedir?

Düşünün ki dev bir matrisiniz var (modelin ağırlıkları). Biz bu matrisin kendisini değiştirmek yerine, onun yanına çok daha küçük iki matris ekliyoruz. Bu iki küçük matrisin çarpımı, orijinal matristeki değişimi temsil ediyor. Örneğin, 200 milyon parametreyi temsil etmek için sadece 120 bin parametre eğitmemiz yetiyor. İşte bu "matematiksel hile", evdeki bilgisayarlarımızda bile yapay zeka eğitmemizi sağlıyor.

Teknik Derinleşme: Unsloth ve Model Yükleme

Unsloth kütüphanesi, Hugging Face ve Llama.cpp kütüphanelerini temel alarak optimizasyonlar yapar. Bellek kullanımını %70'e kadar azaltırken hızı 2 kat artırabilir. İlk adım olarak modelimizi 4-bit kuantize edilmiş halde yüklüyoruz:

from unsloth import FastLanguageModel
import torch

max_seq_length = 2048 # İstediğiniz uzunluk
dtype = None # Otomatik algılama
load_in_4bit = True # Bellek dostu eğitim için

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "unsloth/llama-3-8b-Instruct-bnb-4bit",
    max_seq_length = max_seq_length,
    dtype = dtype,
    load_in_4bit = load_in_4bit,
)

Veri Seti Hazırlığı: Nutuk'u Modele Öğretmek

Bir önceki dersimizde hazırladığımız 4300 soruluk Nutuk veri setini, modelin "sohbet" edebilmesi için ShareGPT formatına çeviriyoruz. Modelin sadece soruyu değil, bir sohbet akışını (User -> Assistant) anlaması için "Conversation" yapısını kuruyoruz:

def formatting_prompts_func(examples):
    instructions = examples["instruction"]
    inputs       = examples["input"]
    outputs      = examples["output"]
    texts = []
    for instruction, input, output in zip(instructions, inputs, outputs):
        # Modelin chat template'ine göre formatlama
        text = f"### Instruction:\n{instruction}\n\n### Input:\n{input}\n\n### Response:\n{output}"
        texts.append(text)
    return { "text" : texts, }

# Veri setini yükleme ve formatlama adımı burada gerçekleşir

Eğitim Parametreleri ve Optimizasyon

Eğitim esnasında en önemli parametrelerden biri Rank (R) değeridir. Bu değer, adaptörün ne kadar karmaşık olacağını belirler. Biz bu örnekte R=16 kullandık. Daha yüksek değerler daha fazla öğrenme kapasitesi sunsa da bellek maliyetini artırır. 17 dakikalık bir eğitim sonucunda modelin "loss" değerinin 2.7'den 1.2'ye düştüğünü gözlemledik.

Önemli Not: Fine-tuning yapmadan önce model Sivas Kongresi sorularına İngilizce cevap verirken, eğitim sonrası veri setimizdeki üslupla Türkçe ve net cevaplar vermeye başladı.

Sıkça Sorulan Sorular (SSS)

1. Kendi veri setimle bu eğitimi yapabilir miyim?
Kesinlikle. Tek yapmanız gereken verilerinizi "Soru-Cevap" formatında bir JSON veya CSV dosyasına dönüştürmek ve videoda gösterdiğimiz formatting_prompts_func fonksiyonuyla modele sunmaktır.

2. LoRA Rank (R) değerini nasıl belirlemeliyim?
Genellikle 8, 16 veya 32 değerleri standarttır. Eğer modeliniz çok karmaşık bir konuyu (örneğin ileri düzey tıp veya hukuk) öğreniyorsa rank değerini artırabilirsiniz, ancak aşırı öğrenme (overfitting) riskine dikkat etmelisiniz.

3. Google Colab'ın ücretsiz GPU'su yeterli mi?
Evet, Unsloth kütüphanesinin 4-bit optimizasyonu sayesinde LLAMA 3 (8B) modelini ücretsiz T4 GPU'da sorunsuzca eğitebilirsiniz. Bellek kullanımımız yaklaşık 13-15 GB civarında seyretmektedir.

Sonuç

Özetle; doğru araçları (Unsloth), doğru yöntemleri (QLoRA) ve kaliteli bir veri setini (Nutuk) bir araya getirdiğinizde, devasa dil modellerini kendi ihtiyaçlarınıza göre özelleştirmeniz artık hayal değil. Bu model artık sadece genel bir dil modeli değil, aynı zamanda Nutuk konusunda uzmanlaşmış bir asistandır.

Daha Fazlasını Keşfedin:
Yapay zeka ve yazılım dünyasındaki gelişmeleri kaçırmamak için Murat Karakaya Akademi YouTube kanalına abone olun.

Kanalı Ziyaret Et & Abone Ol 🚀

#MuratKarakayaAkademi #FineTuning #Llama3 #Unsloth #Nutuk #YapayZeka #DeepLearning #Python

Teknofest Yapay Zeka Yarışması: Tıp Doktorundan Derece Tüyoları

noreply@blogger.com (Murat Karakaya) — Thu, 22 Jan 2026 12:51:00 +0000

Teknofest Sağlıkta Yapay Zeka Yarışması: Bir Tıp Doktorunun Dereceye Uzanan Yolculuğu

Merhabalar arkadaşlar, Murat Karakaya Akademi kanalına ve bloğuna hoş geldiniz. Bugün, özellikle yapay zekaya ilgi duyan ancak "Ben mühendis değilim, bu işi yapabilir miyim?" diye soran herkes için ilham verici bir başarı hikayesini ve teknik bir rehberi paylaşıyoruz.

Konuğumuz, 2019 Çapa Tıp mezunu olan ve mesleğini icra ederken yapay zeka alanında kendini sıfırdan geliştirerek Teknofest "Sağlıkta Yapay Zeka" yarışmasında 5800 takım arasından finalist olup 7.lik derecesi elde eden Dr. Alperen Kaban. Bu yazıda, Alperen Hocamızın tecrübelerinden yola çıkarak; sıfırdan öğrenme sürecinden DICOM verilerinin sanatsal işlenişine kadar tüm detayları inceleyeceğiz.

Bu değerli tecrübe aktarımını ve yarışma atmosferini Alperen Hocamızın kendi ağzından dinlemek için videoyu izlemenizi şiddetle öneririm:

Bu Eğitimde Neler Öğreneceksiniz?

Tıp doktoru olarak sıfırdan yapay zeka uzmanlığına geçiş metotları (MIT OCW, Kaggle ve ötesi).
Teknofest Raporlama Aşamaları: Proje Sunuş ve Detay Raporunda jürinin beklediği kritik detaylar.
Tıbbi görüntüleme (DICOM) verileriyle çalışma: 16-bit hassasiyeti ve veri kaybını önleme yolları.
Kaggle ve Teknofest veri setleri arasındaki yapısal farklar ve model stratejileri.
Final alanındaki donanım hazırlığı: Yedek bilgisayarın ve Docker kullanımının önemi.

1. Sıfırdan Başlamak: Bir Doktorun AI Yolculuğu

Dr. Alperen Kaban, 2019 yılında mezun olduktan sonra geleneksel yollar yerine programlama öğrenmeye karar veriyor. Sürecini şu şekilde özetliyor: "İlk yıl programlamanın temellerini (C ve Python) öğrendim. Google'ın AlphaGo belgeseli beni çok etkiledi ve bu alanın dünyayı değiştireceğine inandım."

Hocamızın önerdiği kaynak rotası ise altın değerinde:

MIT OCW (OpenCourseWare): Özellikle bilgisayar bilimi temelleri için 6.001 gibi dersler.
YouTube ve Udemy: Uygulamalı projeler (Tutorials).
Kaggle: Bitmiş yarışmaların çözümlerini incelemek ve lider tablolarındaki yöntemleri analiz etmek.

2. Teknofest Raporlama ve Strateji: Sadece Kod Yetmez

Teknofest, sadece en yüksek skoru alanın kazandığı bir yer değildir. Süreç; Proje Sunuş Raporu, Proje Detay Raporu ve Finaller şeklinde üç aşamadan oluşur. Alperen Hoca, birçok takımın "raporlama" aşamasında elendiğine dikkat çekiyor.

Raporun Püf Noktaları:

Literatür Taraması: Amerika'yı yeniden keşfetmeyin. Benzer problemler için hangi makaleler neyi önermiş? (Örn: Segmentasyon için Unet mi, Mask R-CNN mi?)
Özgün Değer: Siz bu literatürün üzerine ne koyuyorsunuz? Hangi veri artırma (Augmentation) tekniklerini denediniz?
Analitik Yaklaşım: ChatGPT ile doldurulmuş basit metinler yerine; verinin istatistiksel analizini, sınıf dengesizliğini ve preprocessing (ön işleme) basamaklarını detaylandırın.

3. Teknik Derinlik: DICOM ve Ön İşleme (Preprocessing)

Tıbbi verilerle çalışırken en büyük hata, DICOM dosyalarını standart JPG gibi görmektir. DICOM dosyaları 16-bit veri ve metadata (üst veri) barındırır. Hocamızın vurguladığı gibi: "16-bit veriyi yanlışlıkla 8-bit'e cast ederseniz, teşhis koyduracak o minik piksel farklarını kaybedersiniz."

Aşağıdaki Python örneği, BT (Bilgisayarlı Tomografi) verilerini doğru şekilde normalize etmek ve "Hounsfield Unit" (HU) dönüşümü yapmak için temel bir çerçeve sunar:

import pydicom
import numpy as np

def dicom_to_tensor(filepath):
    # DICOM dosyasını metadata ile oku
    ds = pydicom.dcmread(filepath)
    image = ds.pixel_array.astype(float)
    
    # Metadata'dan Rescale Slope ve Intercept değerlerini al
    # Bu değerler BT görüntülerindeki HU değerlerini hesaplamak için şarttır!
    slope = ds.RescaleSlope if 'RescaleSlope' in ds else 1
    intercept = ds.RescaleIntercept if 'RescaleIntercept' in ds else 0
    
    # Gerçek HU değerlerine dönüştür
    image = (image * slope) + intercept
    
    # Windowing (Pencereleme) - Akciğer için örnek: Center -600, Width 1500
    win_center, win_width = -600, 1500
    img_min = win_center - win_width // 2
    img_max = win_center + win_width // 2
    
    # Sınırları aşan pikselleri kırp (Clipping)
    image = np.clip(image, img_min, img_max)
    
    # 0-1 Normalizasyonu
    image = (image - img_min) / (img_max - img_min)
    
    return image

Dikkat Edilmesi Gerekenler: Maske (Segmentasyon) verileri her zaman iyi organize edilmiş olmayabilir. Zip dosyalarının içindeki klasör yapılarını manuel analiz etmek gerekebilir.

4. Kaggle vs. Teknofest Farkı

Dr. Alperen Kaban'a göre iki platformun veri yapıları çok farklıdır:

Kaggle: Veri seti çok büyük ve gürültülüdür (Noisy). Modelin "genellenebilirliği" (Generalization) daha zordur.
Teknofest: Veri seti daha "butik" ve temizdir. Radyologlar tarafından 3 aşamalı kontrolden geçirilmiş, kesin tanılı verilerdir. Ancak veri az olduğu için Overfitting (Aşırı öğrenme) riskine karşı dikkatli olunmalıdır.

5. Final Günü Hazırlığı: Sınav Atmosferi

Final alanına geldiğinizde sadece yazılım bilginiz değil, kriz yönetiminiz de test edilir. Hocamızın hayati önerileri:

İnternetsiz Çalışma: Alanda internet çok yavaş veya kesik olabilir. Tüm kütüphaneleri (PyTorch, TF, OpenCV) önceden kurup, modellerinizi internetsiz çalışacak şekilde yedekleyin.
Donanım: Yanınızda mutlaka güçlü bir yedek bilgisayar götürün. Final çıkarımı (Inference) için sınırlı süreniz (genelde 1 saat) olacak.
Formatlar: Sonuçları genelde bir JSON objesi olarak yüklemeniz beklenir. Kodunuzun bu formatı hatasız ürettiğinden emin olun.

Sıkça Sorulan Sorular (SSS)

1. Mühendislik okumayan biri bu yarışmada başarılı olabilir mi?
Evet! Alperen Hocamız bunun en canlı örneğidir. Ciddi bir çalışmayla (yaklaşık 1-2 yıl) bir bilgisayar mühendisi seviyesine gelmek mümkündür.

2. Yarışmada bulut tabanlı (Colab/Kaggle) araçlar kullanılabilir mi?
Ön hazırlık aşamasında evet, ancak final anında internet kullanımı yasak olabilir. Tüm işlemlerinizi yerel (local) donanımınızda yapabilmelisiniz.

3. Takım kurarken nelere dikkat edilmeli?
Görev dağılımını en baştan yapın (Veri temizliği, Rapor yazımı, Model eğitimi). İletişim sorunu olmayan, disiplinli arkadaşları seçmek "zaman çizelgesine" uymak için kritiktir.

Sonuç

Yapay zeka sadece bilgisayar mühendislerinin tekelinde değil; her disiplinden gelen uzmanın kendi bilgisiyle harmanladığında devrim yaratabileceği bir alandır. Alperen Hocamızın başarısı, sabır ve doğru kaynak takibinin sonucudur. Siz de Teknofest'e katılarak bu ekosistemin bir parçası olabilirsiniz.

Daha Fazlasını Keşfedin:
Yapay zeka, derin öğrenme ve modern yazılım dünyasındaki güncel gelişmeleri, Türkçe ve İngilizce anlatımlarla takip etmek için Murat Karakaya Akademi kanalımıza davetlisiniz.

Kanalı Ziyaret Et & Abone Ol 🚀

#MuratKarakayaAkademi #Teknofest #YapayZeka #SağlıktaYapayZeka #DeepLearning #Python #DICOM #DrAlperenKaban

İnce Ayar (Fine-Tuning): QLoRA Adaptörünü GGUF Formatına Dönüştürme ve Ollama Entegrasyonu

noreply@blogger.com (Murat Karakaya) — Thu, 22 Jan 2026 12:47:00 +0000

İnce Ayar (Fine-Tuning) Serisi: QLoRA Adaptörünü GGUF Formatına Dönüştürme ve Ollama Entegrasyonu

Değerli arkadaşlar, Murat Karakaya Akademi'ye hoş geldiniz. İnce ayar (Fine-Tuning) eğitim serimizin dördüncü ve tamamlayıcı bölümüyle karşınızdayım. Hatırlarsanız bu seriye veri setimizi hazırlayarak başlamış, ardından temel kavramları incelemiş ve üçüncü videomuzda Llama 3 modelini "Nutuk" verisiyle Unsloth kütüphanesini kullanarak eğitmiştik.

Bugünkü dersimizde ise eğittiğimiz bu QLoRA adaptörünü, baz (base) model ile birleştirip tek bir dosya haline getireceğiz. Daha sonra bu modeli GGUF formatına dönüştürüp 4-bit quantization (nitelik kaybı olmadan boyut küçültme) işlemini uygulayacağız. Son olarak da elde ettiğimiz bu modeli Ollama ve Llama.cpp kullanarak yerel bilgisayarımızda nasıl çalıştırabileceğimizi adım adım göreceğiz. Bu işlem, eğittiğiniz modelleri dağıtmak ve CPU üzerinde bile hızlıca çalıştırmak için kritik bir adımdır.

Bu teknik süreci uygulamalı olarak görmek, kodları adım adım takip etmek ve modelin canlı performansını izlemek için videoyu izlemenizi öneririm:

Bu Eğitimde Neler Öğreneceksiniz?

QLoRA adaptörünün baz model (Llama 3) ile birleştirilmesi (Merging).
Unsloth kütüphanesi ile GGUF formatına dönüşüm ve 4-bit Quantization.
Modelin Hugging Face Hub üzerine yüklenmesi.
Eğitilen modelin Ollama ve Llama.cpp ile yerel bilgisayarda çalıştırılması.
Gradio kullanarak model için basit bir sohbet arayüzü oluşturulması.

Neden Birleştirme (Merging) ve GGUF?

Bir önceki dersimizde modelimizi QLoRA tekniği ile eğitmiş ve elimizde sadece eğitilen parametreleri içeren küçük bir "adaptör" dosyası kalmıştı. Ancak modeli kullanmak istediğimizde hem devasa baz modeli hem de adaptörü aynı anda yüklememiz gerekiyordu. Bu durum hem bellek yönetimi açısından zorlayıcıdır hem de çıkarım (inference) hızını düşürür.

Bugün yapacağımız "Merging" işlemi ile adaptörü baz modelin içine gömeceğiz. Ardından yapacağımız GGUF dönüşümü ile modeli tek bir dosya haline getirip, Apple Silicon (Mac) veya standart CPU'lu bilgisayarlarda bile çok hızlı çalışabilir hale getireceğiz. Unsloth kütüphanesi, normalde Llama.cpp ile yapılan bu karmaşık işlemi bizim için çok basit bir hale getiriyor.

Unsloth ile GGUF Dönüşümü ve Hugging Face Upload

Unsloth kütüphanesi, modelin kaydedilmesi aşamasında bize save_pretrained_gguf metodunu sunar. Bu metod sayesinde hem 16-bit (orijinal) hem de 4-bit (quantize edilmiş) versiyonları tek komutla oluşturabilir ve Hugging Face hesabımıza yükleyebiliriz.

Aşağıdaki kod bloğunda, eğittiğimiz modelin "q4_k_m" (4-bit medium) formatında dönüştürülüp yüklenmesini görüyoruz:

# Modeli GGUF formatında kaydetme ve Hugging Face'e yükleme
model.push_to_hub_gguf(
    "hf_kullanici_adiniz/Nutuk-Llama-3-8B-GGUF", # Hugging Face Repo Adı
    tokenizer,
    quantization_method = "q4_k_m", # Yaygın kullanılan 4-bit quantization
    token = "hf_token_buraya_gelecek" # Hugging Face Token'ınız
)

Ollama ile Yerelde Çalıştırma

Modelimiz Hugging Face üzerinde GGUF formatında hazır olduğunda, artık onu Ollama ile çalıştırmak çocuk oyuncağı. Ollama'nın yeni özelliklerinden biri, doğrudan Hugging Face üzerindeki GGUF dosyalarını indirip çalıştırabilmesidir.

Google Colab veya yerel terminalinizde şu komutu kullanarak modeli indirebilir ve sohbeti başlatabilirsiniz:

# Ollama'yı arka planda çalıştırın (Linux/Colab için)
ollama serve &

# Hugging Face üzerindeki GGUF modelini çalıştırın
ollama run hf.co/hf_kullanici_adiniz/Nutuk-Llama-3-8B-GGUF

Python ve Gradio ile Arayüz Oluşturma

Sadece terminalden değil, Python kodları içerisinden de modelimize erişebiliriz. Videoda gösterdiğim gibi, llama-cpp-python kütüphanesini kullanarak bir çıkarım (inference) fonksiyonu yazabilir ve bunu Gradio ile basit bir web arayüzüne dönüştürebiliriz.

from llama_cpp import Llama

# Modeli yükle (Hugging Face'den indirdiğiniz GGUF dosya yolu)
llm = Llama(
    model_path="./Nutuk-Llama-3-8B.Q4_K_M.gguf",
    chat_format="llama-3"
)

# Örnek sorgu
response = llm.create_chat_completion(
    messages=[
        {"role": "user", "content": "Sivas Kongresi ne zaman yapıldı?"}
    ]
)

print(response['choices'][0]['message']['content'])

Sıkça Sorulan Sorular (SSS)

1. Neden modeli GGUF formatına çeviriyoruz?
GGUF formatı, modelin tek bir dosya içinde tutulmasını sağlar ve özellikle CPU (işlemci) üzerinde çalıştırmak için optimize edilmiştir. Ayrıca 4-bit quantization ile model boyutu 16GB'lardan 4-5GB seviyelerine düşer, bu da standart bilgisayarlarda çalışmasını mümkün kılar.

2. Unsloth kullanmadan bu işlemi yapabilir miyim?
Evet, llama.cpp kütüphanesini doğrudan kullanarak da dönüşüm yapabilirsiniz ancak bu süreç çok daha manuel ve karmaşıktır. Unsloth, bu süreci optimize ederek arka planda gerekli dönüşümleri otomatik yapar.

3. Eğittiğim modeli ticari olarak kullanabilir miyim?
Bu, temel aldığınız modelin (Llama 3) lisansına ve kullandığınız veri setinin telif haklarına bağlıdır. Llama 3 genellikle açık bir lisansa sahiptir ancak "Nutuk" gibi kamuya mal olmuş veriler dışında özel veri setleri kullanıyorsanız dikkatli olmalısınız.

Sonuç

Bu eğitimle birlikte, veri seti hazırlamadan başlayıp, modeli eğitme ve son kullanıcıya sunulabilir bir formata (GGUF) dönüştürme sürecini tamamlamış olduk. Artık kendi özelleştirilmiş yapay zeka modellerinizi oluşturup, şirketinizde veya kişisel projelerinizde internete ihtiyaç duymadan (lokal olarak) çalıştırabilirsiniz.

Daha Fazlasını Keşfedin:
Yapay zeka, Büyük Dil Modelleri (LLM) ve yazılım dünyasındaki en güncel gelişmeleri teknik derinlikle öğrenmek için Murat Karakaya Akademi YouTube kanalına abone olun.

Kanalı Ziyaret Et & Abone Ol 🚀

#MuratKarakayaAkademi #FineTuning #Llama3 #GGUF #Ollama #YapayZeka

Google Gemma 3: Türkçe Destekli Açık Kaynak Yapay Zeka Devrimi

noreply@blogger.com (Murat Karakaya) — Thu, 22 Jan 2026 09:39:00 +0000

Google Gemma 3: Türkçe Destekli Açık Kaynak Yapay Zeka Devrimi

Merhabalar arkadaşlar, hoş geldiniz. Bugün sizlerle Google DeepMind tarafından yayınlanan ve yapay zeka dünyasında, özellikle açık kaynak modeller tarafında büyük ses getiren Gemma 3 modelini derinlemesine inceleyeceğiz.

Biliyorsunuz, açık kaynak dünyası hızla gelişiyor ancak Türkçe dil desteği konusunda her zaman bazı kısıtlarla karşılaşıyorduk. Gemma 3, 128.000 token bağlam penceresi (context window) ve resmi Türkçe desteği ile oyunun kurallarını değiştiriyor olabilir. Peki, 4 milyar parametreli "küçük" bir model, 27 milyarlık abileriyle veya ChatGPT gibi devlerle yarışabilir mi? Gelin, teknik detaylara ve performans testlerine birlikte bakalım.

Bu konuyu uygulamalı olarak görmek, kodları adım adım takip etmek ve modelin canlı performans testlerini izlemek için videoyu izlemenizi şiddetle öneririm:

Bu Eğitimde Neler Öğreneceksiniz?

Gemma 3'ün teknik mimarisi ve getirdiği yenilikler (Multimodal yapı).
Modelin Türkçe dil performansı, mantık ve muhakeme yetenekleri.
4B ve 27B modellerin donanım gereksinimleri (VRAM tüketimi).
Açık kaynak modellerin yerel bilgisayarda çalıştırılması.
RAG ve Agent (İş Gören) sistemlerinde kullanım potansiyeli.

Gemma 3 Nedir ve Neden Önemli?

Google'ın "Gemma" serisi, aslında kapalı kaynak olan Gemini modellerinin teknolojisiyle üretilmiş, ağırlıkları (weights) halka açılmış versiyonlarıdır. Gemma 3 ile birlikte Google, sadece ağırlıkları değil, teknik raporu da yayınlayarak şeffaflık konusunda önemli bir adım attı.

Bu modelin en çarpıcı özelliği Multimodal (Çok Modlu) olmasıdır. Yani modele hem metin hem de görsel verip, metin çıktısı alabilirsiniz. Ayrıca daha önceki versiyonlarda 8K olan bağlam penceresi, Gemma 3 ile 128K seviyesine çıkarılmış. Bu, yaklaşık olarak yüzlerce sayfalık bir kitabı tek seferde modele verip üzerinde konuşabileceğiniz anlamına gelir.

Türkçe Performansı ve Tokenizer Devrimi

Videodaki testlerimizde gördük ki, Gemma 3 özellikle Türkçe konusunda çok başarılı. Bunun arkasındaki temel sebep, Google'ın Tokenizer yapısını değiştirmesidir. Eski modeller genellikle İngilizce ağırlıklı eğitildiği için Türkçe kelimeleri çok fazla parçaya bölüyor ve anlam bütünlüğünü kaybedebiliyordu. Gemma 3, 140 dili kapsayan özel eğitim setiyle Türkçeyi "anadil" seviyesine yakın bir akıcılıkta işliyor.

Mantık ve Muhakeme Testleri

4 milyar parametreli (4B) versiyonu 4-bit quantize edilmiş haliyle test ettik. Şaşırtıcı sonuçlar aldık:

Oğuz Atay Özeti: "Tutunamayanlar" kitabından ağır bir paragrafı başarıyla ve felsefi derinliği koruyarak özetledi.
Mantık Soruları: Klasik "kuruyan gömlek" veya "otobüs durağı" sorularında, kendisinden çok daha büyük modellerin (hatta bazen GPT-4 seviyesindeki modellerin) düştüğü tuzaklara düşmedi. Kendi hatasını fark edip düzeltebilen bir yapı sergiledi.

Kodlama ve Teknik Kurulum

Gemma 3'ü yerel bilgisayarınızda çalıştırmak için Unsloth, Hugging Face Transformers veya Ollama kullanabilirsiniz. 4B modeli çalıştırmak için yaklaşık 7-8 GB VRAM (veya RAM) yeterli oluyor. Bu da ortalama bir oyun bilgisayarında veya Apple Silicon işlemcili bir Mac'te rahatlıkla çalışabileceği anlamına gelir.

Aşağıda, modeli Python ortamında `unsloth` kütüphanesi ile nasıl yükleyebileceğinize dair basit bir örnek paylaşıyorum:

from unsloth import FastLanguageModel
import torch

# 4-bit quantization ile modeli yükle (Daha az bellek kullanımı için)
max_seq_length = 2048
dtype = None 
load_in_4bit = True 

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "unsloth/gemma-3-4b-it-bnb-4bit", 
    max_seq_length = max_seq_length,
    dtype = dtype,
    load_in_4bit = load_in_4bit,
)

# Inference (Tahmin) Moduna Al
FastLanguageModel.for_inference(model)

# Prompt Formatı
messages = [
    {"role": "user", "content": "Bana Python'da bir QuickSort algoritması yazabilir misin?"},
]

inputs = tokenizer.apply_chat_template(
    messages,
    tokenize = True,
    add_generation_prompt = True,
    return_tensors = "pt",
).to("cuda")

# Çıktı Üret
outputs = model.generate(input_ids = inputs, max_new_tokens = 1024, use_cache = True)
print(tokenizer.batch_decode(outputs)[0])

Bu kod bloğu, Unsloth kütüphanesinin optimize edilmiş yapısını kullanarak modeli çok daha hızlı ve az bellek tüketerek çalıştırmanızı sağlar.

Sıkça Sorulan Sorular (SSS)

1. Gemma 3 tamamen ücretsiz mi?
Evet, Gemma 3 açık ağırlıklı (open weights) bir modeldir. Ticari kullanım şartlarına (Google'ın lisansına) uymak kaydıyla projelerinizde ücretsiz kullanabilirsiniz.

2. ChatGPT yerine kullanılabilir mi?
Günlük sohbetler için ChatGPT daha geniş bir genel kültüre sahip olabilir. Ancak veri gizliliğinin önemli olduğu şirket içi projelerde, RAG (Retrieval Augmented Generation) sistemlerinde ve yerel "Agent" (İş Gören) uygulamalarında Gemma 3 harika bir alternatiftir.

3. Hangi donanıma ihtiyacım var?
4 milyar parametreli (4B) modeli çalıştırmak için 8GB RAM/VRAM yeterlidir. 27 milyar parametreli (27B) versiyonu verimli çalıştırmak için ise RTX 3090 veya 4090 gibi en az 24GB VRAM'e sahip kartlar önerilir.

Sonuç

Özetle, Google Gemma 3, özellikle Türkçe doğal dil işleme projeleri geliştirmek isteyen mühendisler, öğrenciler ve araştırmacılar için muazzam bir fırsat. Açık kaynak olması, yerelde çalışabilmesi ve mantıksal çıkarım yeteneğinin boyutuna göre çok yüksek olması onu öne çıkarıyor. Projelerinizde API maliyetlerinden kurtulmak ve verinizi dışarı çıkarmadan işlemek istiyorsanız, Gemma 3'ü mutlaka test etmelisiniz.

#MuratKarakayaAkademi #Gemma3 #YapayZeka #LLM #DeepLearning #Python

Google Gemma 3 Vision: Python ile Görüntü İşleme, OCR ve Tarihi Analiz Deneyimleri

noreply@blogger.com (Murat Karakaya) — Thu, 22 Jan 2026 09:33:00 +0000

Google Gemma 3 Vision: Python ile Görüntü İşleme, OCR ve Tarihi Analiz Deneyimleri

Merhaba değerli arkadaşlar, ben Prof. Dr. Murat Karakaya. Murat Karakaya Akademi'ye hoş geldiniz. Bugün hem teknik hem de manevi açıdan çok özel bir inceleme ile karşınızdayım. 18 Mart Çanakkale Zaferi vesilesiyle, Google'ın yeni multimodal modeli Gemma 3 (4B)'ü, Çanakkale Savaşı'na ait tarihi fotoğraflar, belgeler ve menüler üzerinde test ettik.

Amacımız şu: Sadece 4 milyar parametreli küçük bir model, karmaşık tarihi belgeleri okuyabilir mi (OCR)? Yıpranmış siyah beyaz fotoğraflardaki duyguyu ve bağlamı anlayabilir mi? Ve en önemlisi, bunları Türkçe olarak hatasız yorumlayabilir mi? Sonuçlar beni gerçekten şaşırttı. Gelin, bu deneyimi ve Python kodlarını birlikte inceleyelim.

Bu duygusal ve teknik analizi baştan sona izlemek, modelin tarihi belgeleri nasıl yorumladığına şahit olmak için videoya göz atmanızı öneririm:

Bu Eğitimde Neler Öğreneceksiniz?

Hugging Face Transformers kütüphanesi ile Gemma 3 Vision kurulumu.
Gemma 3'ün OCR (Optik Karakter Tanıma) performansı ve kalori hesabı örneği.
Eski ve yıpranmış fotoğraflarda duygu ve bağlam analizi.
Yabancı dildeki (İngilizce/Yunanca) tarihi belgelerin analizi ve çevirisi.
Python ile Multimodal (Resim + Metin) pipeline oluşturma.

Gemma 3 Vision ve Teknik Altyapı

Gemma 3, sadece metin üreten bir LLM değil, aynı zamanda görüntüleri de "görebilen" bir VLM (Vision Language Model). Modelin içinde bir Vision Encoder bulunuyor. Bu encoder, görüntüyü küçük parçalara (patch) bölüyor, token'lara çeviriyor ve dil modelinin anlayabileceği bir formata dönüştürüyor.

Bu çalışmada, henüz çok yeni olduğu için Hugging Face'in transformers kütüphanesinin geliştirici sürümünü (GitHub branch) kullandık. Model olarak da 4 milyar parametreli (4B-it) versiyonu tercih ettik. Neden? Çünkü Colab'ın ücretsiz T4 GPU'sunda veya standart bir bilgisayarda (yaklaşık 7-8 GB VRAM ile) rahatlıkla çalışabiliyor.

Çanakkale Özel: Model Neleri Başardı?

1. OCR ve Mantıksal Çıkarım (Asker Menüsü)

Modele, Çanakkale Savaşı'nda askerlerimize verilen yemek listesini (15 Haziran, 26 Haziran gibi tarihlerin ve öğünlerin yazdığı eski bir belge) gösterdik. Gemma 3'ten sadece okumasını değil, askerlerin günlük kalorisini hesaplamasını ve günümüz hamburger menüsüyle kıyaslamasını istedik.

Sonuç: Model, tablodaki "Üzüm Hoşafı", "Yarım Ekmek" gibi silik yazıları kusursuz okudu. Askerin günlük ortalama 270 kalori aldığını hesapladı ve bunu günümüzün 1100 kalorilik menüsüyle kıyaslayarak aradaki uçurumu (yokluğu ve fedakarlığı) çok net ortaya koydu.

2. Duygu Analizi (Siperdeki Askerler)

Atatürk'ün cephede gözlemlediği anları anlattığı bir mektubun görselini ve siperdeki askerlerin bir fotoğrafını verdik. "Buradaki ruh halini özetle" dedik. Model, askerlerin yüzündeki kararlılık, korku, gerginlik ve vatan sevgisi ifadelerini metinle birleştirerek lise düzeyinde bir öğrencinin yazabileceği kalitede duygusal bir analiz yaptı.

3. Bağlamı Anlama (Fotoğraf Nerede Çekildi?)

Hiçbir yazı içermeyen, sadece askerlerin olduğu bir fotoğraf gösterdik. Model, üniformalardan, kask yapısından (her ne kadar kalpak yerine kask dese de) ve ortamdan bunun 1. Dünya Savaşı, Osmanlı Cephesi olduğunu ve muhtemelen Çanakkale veya Filistin cephesi olabileceğini "akıl yürüterek" buldu.

Python Kodları: Gemma 3 Vision Kurulumu

Bu analizi kendi bilgisayarınızda veya Google Colab'da yapmak için aşağıdaki Python kodlarını kullanabilirsiniz. Transformers kütüphanesinin güncel olduğundan emin olun.

import torch
from transformers import pipeline
from PIL import Image
import requests

# 1. Pipeline'ı Hazırlama
# 'image-text-to-text' görevi multimodal modeller içindir.
pipe = pipeline(
    "image-text-to-text",
    model="google/gemma-3-4b-it",
    device_map="auto",
    torch_dtype=torch.bfloat16 # Bellek tasarrufu için bfloat16 önemli
)

# 2. Resmi Yükleme (Örnek URL)
image_url = "https://example.com/canakkale_fotografi.jpg"
image = Image.open(requests.get(image_url, stream=True).raw)

# 3. Modele Mesaj Gönderme
# Gemma 3 için özel mesaj formatı
messages = [
    {
        "role": "user",
        "content": [
            {"type": "image", "image": image},
            {"type": "text", "text": "Bu resimde ne görüyorsun? Askerlerin ruh halini ve ortamı detaylıca analiz et."}
        ]
    }
]

# 4. Cevabı Üretme
output = pipe(messages, max_new_tokens=1024)
print(output[0]["generated_text"][-1]["content"])

Sıkça Sorulan Sorular (SSS)

1. Gemma 3 Türkçe OCR konusunda ne kadar başarılı?

4 milyar parametreli bir model için inanılmaz başarılı. Çanakkale menüsündeki eski yazı tiplerini, Atatürk'ün el yazısına yakın notlarını ve yıpranmış gazete küpürlerini %95'in üzerinde doğrulukla okuyup Türkçeye çevirebildi.

2. Bu model sadece CPU ile çalışır mı?

Evet, Llama.cpp gibi araçlarla CPU üzerinde çalıştırılabilir ancak bu rehberde kullandığımız Transformers kütüphanesi ile GPU (Colab T4 veya yerel RTX kartlar) kullanmak çok daha hızlı sonuç verir. CPU'da bir resmin analizi dakikalar sürebilir.

3. Llama 3.2 Vision ile farkı nedir?

Gemma 3, özellikle Türkçe dil desteği ve muhakeme (reasoning) yeteneği konusunda çok daha "yerel" hissettiriyor. Yaptığımız testlerde Türk tarihi ile ilgili bağlamları (üniformalar, coğrafya) şaşırtıcı derecede doğru tanıdı.

Sonuç

Bu 18 Mart'ta, teknolojiyi tarihimizi anlamak için kullandık. Gemma 3, 4 milyar parametresine rağmen, o dönemin zorluklarını, askerimizin fedakarlığını ve tarihin tozlu sayfalarındaki detayları bize bir kez daha, yapay zeka gözüyle gösterdi. Bize bu vatanı emanet eden tüm kahramanlarımızı saygı ve rahmetle anıyoruz.

Daha Fazlasını Keşfedin:
Yapay zeka modellerinin sınırlarını zorladığımız, teknik analizleri milli değerlerimizle harmanladığımız videoları kaçırmamak için Murat Karakaya Akademi YouTube kanalına abone olun.

Kanalı Ziyaret Et & Abone Ol 🚀

#MuratKarakayaAkademi #Gemma3 #VisionAI #CanakkaleZaferi #YapayZeka #Python