Artificial Intelligence • R&D • Project Management

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

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

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

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

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ü?

1. Kara Kutu (Black Box): Model sadece "75" döndürdü. Neden 75? 74 veya 80 değil? Bilmiyoruz.
2. Subjektiflik: Aynı metinlere bir gün 60, ertesi gün 85 verebilir.
3. 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ışı:

1. Fonksiyonlar `tools=[...]` listesiyle modele tanıtılır. 2. Model gerekiyorsa `response.message.tool_calls` üretir. 3. Python bu tool call'ları çalıştırır. 4. Sonuçlar `role="tool"` mesajları olarak konuşmaya eklenir. 5. 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