Ontoloji: AI Ajanlarına Şirketinizin Nasıl Çalıştığını Öğretmek

İngilizce versiyon: 🇺🇸 English.

LLM’ler dünyaya dair genel bilgiye sahip olabilir. Fakat şirketinizin domainlerini, bu domainlerdeki kavramları ve domain kurallarını kendiliğinden bilmez. Bu yüzden AI agent’larınız da şirketinizin nasıl çalıştığını kendiliğinden bilemez.

Bir agent şirketinizdeki tablolara, belgelere ve API’lere erişebilir. Yine de verified customerın ne olduğunu yanlış anlayabilir. Çünkü erişim, anlayış değildir.

Ontoloji ilk bakışta kavramsal bir konu gibi görünebilir. Oysa bunu AI agent’larla çalışan bir şirkette uygulamak; domain modelleme, veri ve entegrasyon mimarisi, güvenlik ve yetkilendirme, business rule’lar, workflow tasarımı ve LLM sistemleri hakkında birlikte düşünmeyi gerektirir.

Ontolojiyi gerçek bir iş akışında hayata geçirmek, tek bir ekibin oluşturacağı bir şema değildir. Domain sahipleri iş anlamını, data ve platform ekipleri kaynakları, yazılım ve AI ekipleri araçları ve aksiyonları, product ve security ekipleri ise değer ve sınırları birlikte netleştirir. AI/ML ve data science ekipleri de retrieval ve değerlendirme süreçlerine katkı sağlar, bu modelin agent performansına etkisini ölçer.

Bu nedenle ontology, yalnızca bir graph database veya modelleme projesi değildir. Şirketin nasıl çalıştığına dair ortak bir anlayışı farklı ekiplerin birlikte tasarladığı, yaşayan bir kurumsal modeldir.

AI agent nedir?

AI agent, bir hedefi gerçekleştirmek için ortamını gözlemleyen, plan yapan, araç seçip çağıran, sonuçları değerlendiren ve gerektiğinde planını değiştiren yazılım sistemidir. LLM bu sistemin akıl yürütme parçasıdır; agent’ın tamamı değildir. Talimatlar, bağlam, araçlar, izinler, bellek, durma koşulları ve insan onayı da sistemin parçasıdır.

Basit bir sohbet robotu çoğunlukla soruya yanıt üretir. Agent ise örneğin CRM’den güncel bilgiyi okuyabilir, bir servisi çağırabilir, sonucu kontrol edebilir ve bir sonraki adımı seçebilir. En basit agent döngüsü şöyledir:

Hedef → gözlem → planlama → araç çağrısı → sonuç → doğrulama → yanıt veya aksiyon

Burada önemli bir ayrım var. Adımları ve karar noktaları önceden kodlanmışsa bu bir workflow’dur. LLM hangi aracı hangi sırayla kullanacağına, ara sonuçlara bakarak kendisi karar veriyorsa agentic bir sistemden söz ederiz. Üretimde bu iki yaklaşım çoğu zaman birlikte kullanılır: esnek karar gereken yerde agent, kritik ve öngörülebilir adımlarda workflow. Anthropic’in workflow ve agent ayrımı ile Google Cloud’un agent bileşenleri bu ayrımı farklı açılardan açıklıyor.

Ontoloji nedir?

Domain, şirketin belirli bir iş alanını ve bu alana ait kavramları, ilişkileri ve kuralları ifade eder. Müşteri, sipariş, kredi veya sözleşme buna örnek olabilir.

Ontoloji, bir domain içindeki kavramları, bu kavramlar arasındaki ilişkileri, özellikleri, durumları ve geçerli kısıtları ortak ve makine tarafından yorumlanabilir biçimde tanımlayan modeldir.

Daha basit söylersek ontoloji şu soruları yanıtlar:

• Şirketimizde hangi kavramlar ve varlıklar var?
• Bu kavramlar ne anlama geliyor?
• Birbirleriyle nasıl ilişkililer?
• Hangi durumlar ve geçişler geçerli?
• Hangi koşullarda hangi aksiyonlar yapılabilir?

Customer, Account ve Order birer kavramdır. Bir müşterinin hesabın sahibi olması bir ilişkidir. Bir hesabın active, suspended veya pending durumlarından birinde olması bir durum modelidir. Bir müşterinin ancak e-posta, telefon ve kimlik kontrolleri tamamlandığında doğrulanması bir iş kuralıdır. İade başlatmak veya hesabı askıya almak ise aksiyondur.

Anlamsal Web ve akademik bağlamda ontology daha biçimsel bir kavramdır. W3C’nin OWL 2 standardı, ontolojileri sınıflar, özellikler, bireyler ve veri değerleri içeren, anlamı biçimsel olarak tanımlanmış modeller olarak ele alır. Kurumsal uygulamada her ekip OWL veya RDF kullanmak zorunda değildir; asıl fikir, şirketin iş anlamlarını ortak bir modelde açıkça ifade etmektir.

Bir müşteri doğrulama domain’i için bu model örneğin şöyle görünebilir:

Ontoloji, şema ve bilgi grafiği aynı şey mi?

Bu kavramlar pratikte sıkça birbirine karışır:

Bu ayrım mutlak değildir. Bir bilgi grafiği ontolojiyi ve somut gerçekleri birlikte taşıyabilir; ontology de bir bilgi grafiği kullanılarak uygulanabilir. Fakat ontology bir veritabanı türü değildir. Ayrı bir graf veritabanı olmadan da tablolar, servisler, API’ler ve olay akışları ortak kavramlara bağlanabilir. Depolama tercihi ile anlam modelini birbirine karıştırmamak gerekir.

Ontoloji AI agent’lar için neden önemli?

Bir sohbet robotu kavramı yanlış anlarsa yanlış bir cümle üretebilir. Bir agent aynı kavramı yanlış anlarsa yanlış veriyi seçebilir, yanlış kişiye bilgi gösterebilir veya yanlış bir aksiyon gerçekleştirebilir.

Diyelim ki bir agente şu soruyu sordunuz:

Dün kaç kullanıcı kayıt oldu ve doğrulandı?

Model email_verified = true alanını “doğrulandı” olarak yorumlarsa sonuç 312 olabilir. Oysa şirketinizde doğrulama; e-posta, telefon ve kimlik kontrollerinin üçünün de tamamlanması demekse gerçek sayı 89’dur. Sorgu teknik olarak geçerli, fakat iş açısından yanlıştır.

Bu hata yalnızca bir rapor hatası olarak kalmayabilir. Yönetim yanlış sayıyı bütçe planlamasında, operasyon ekipleri kapasite planlamasında, finans ise gelir tahmininde kullanabilir. Bir kavramın yanlış yorumlanması kısa sürede şirket çapında yanlış karara dönüşebilir.

RAG ilgili dokümanı getirebilir; ancak çelişen tanımlar arasında hangisinin güncel ve otoriter olduğunu tek başına garanti etmez. Text-to-SQL doğal dili tablo ve alanlara çevirebilir; ancak doğru alanın iş tanımına uyduğunu garanti etmez. Tool calling doğru API’yi çağırabilir; ancak aksiyonun o kullanıcı ve bağlam için yetkili olup olmadığını kendi başına belirlememelidir.

Ontology bu adımlar arasında ortak bir zemin kurar:

Kullanıcı niyeti → domain kavramı → kanonik tanım → otoriter kaynak → kural ve izin kontrolü → araç → kanıtlı yanıt veya aksiyon

Bu sayede agent yalnızca “hangi tabloyu sorgulamalıyım?” diye düşünmez. “Bu kelime şirketimizde hangi kavrama karşılık geliyor, bu kavramın güncel kaynağı hangisi, hangi ilişkileri izlemeliyim ve bu aksiyon için hangi ön koşullar geçerli?” sorularına da sistematik bir çerçevede yanıt verir.

Aynı model, yanıt ve aksiyon arasında köprü kurar

Örneğin kullanıcı “Bu müşterinin hesabını şimdi askıya alabilir miyim?” diye sorduğunda agent’ın:

1. Kullanıcının hangi müşteri ve hesap nesnesini kastettiğini çözmesi,
2. Hesabın güncel durumunu ve ilgili sözleşmeyi bulması,
3. Askıya alma kuralının ön koşullarını kontrol etmesi,
4. Kullanıcının bu aksiyon için yetkili olup olmadığını doğrulaması,
5. Gerekirse insan onayı alması,
6. Yalnızca yetkili aksiyon işleyicisini çağırması gerekir.

Ontology bu adımlardaki kavramları ve ilişkileri tanımlar. Yetkilendirme servisi izni, politika motoru kuralı, aksiyon işleyicisi ise gerçek değişikliği uygular. Böylece model karar önerebilir; şirket politikasının veya transaction sınırlarının tek otoritesi olmaz.

Güncel uygulamalar ne gösteriyor?

Kurumsal ürünlerde ontology fikri farklı biçimlerde uygulanıyor. Databricks Genie Ontology, tablolar, sorgular, dashboard’lar ve bağlı uygulamalardan iş terimleri, metrik tanımları, kaynak otoritesi ve business rule’lar çıkaran bir context layer olarak anlatılıyor. Snowflake’in Cortex Agents yazısı ise semantic view üzerine ontology ve knowledge graph ekleyerek hiyerarşi, eş anlamlılık ve domain kısıtlarının agent tarafından kullanılmasını inceliyor. Palantir’in yaklaşımı bu kapsamı daha da genişletip ontology’yi data, logic, action ve security’nin birlikte modellendiği operasyonel bir katman olarak sunuyor.

Bu örneklerin ortak mesajı şu: Agent’a daha fazla doküman vermek tek başına yeterli değildir. Agent’ın şirketin hangi kavramlarla çalıştığını, hangi kaynağa güveneceğini, hangi kurallara uyacağını ve hangi aksiyonları hangi sınırlar içinde çağırabileceğini bilmesi gerekir.

Ontoloji tek başına yetmez

Ontology, şirketin dünyasını ve anlamlarını tanımlar; fakat bu anlamları tek başına uygulamaz. LLM’i yeniden eğitmez, veriyi güncellemez, yetki vermez, API çağırmaz ve işlemi gerçekleştirmez. Ayrıca tek başına yetkilendirme sistemi, politika motoru, veri kalitesi sistemi veya işlem yöneticisi değildir.

Örneğin ontology şunu tanımlayabilir:

“Doğrulanmış müşteri” olmak için e-posta, telefon ve kimlik doğrulamalarının tamamı yapılmış olmalı.

Ancak güvenilir bir agent için başka soruların da cevaplanması gerekir:

• Bu müşterinin güncel verisi nerede?
• Gerçekten hangi müşteri kaydından bahsediyoruz?
• Bu verinin kaynağı güncel ve güvenilir mi?
• Bu kullanıcı müşterinin hesabını görebilir mi?
• Hesabı askıya alma yetkisi var mı?
• Aksiyon hangi API veya servis üzerinden uygulanacak?
• İşlem başarılı oldu mu ve kim tarafından yapıldı?

Bu nedenle güvenilir bir agent sistemi kabaca şu akışla çalışır:

Ontology → veri erişimi → kural ve izin kontrolü → araç/API → işlem → audit kaydı

Ontology bu akışta “bu kavram ne anlama geliyor?” ve “hangi ilişkiler önemli?” sorularının cevabını verir. Yetkilendirme sistemi izni, policy engine iş kuralını, aksiyon işleyicisi gerçek değişikliği, audit sistemi ise sonradan kanıtı yönetir. Ontology hesabı askıya almaz; agent doğru planı önerebilir ama kritik işlemin son kontrolünü deterministik sistemler yapmalıdır.

Güvenilir bir kurumsal agent için en az şu parçalar birlikte çalışmalıdır:

1. İş anlamı: Kavramlar, ilişkiler, eş anlamlılar, durumlar ve istisnalar.
2. Veri eşlemeleri: Kanonik kaynaklar, alanlar, güncellik, sahiplik ve kanıt.
3. Politika ve izinler: Kullanıcının ve agent’ın hangi işlemleri yapabileceği.
4. Araç ve aksiyon sözleşmeleri: Girdi tipleri, ön koşullar, hata davranışı ve yazma sınırları.
5. Değerlendirme ve denetim: Doğru yanıt, doğru kaynak, uygulanan kural ve gerçekleşen aksiyonun kaydı.

Kritik durum geçişleri, para hareketleri, erişim değişiklikleri ve benzeri işlemler yetkili sistemlerde deterministik olarak tekrar kontrol edilmelidir. Agent plan önerebilir ve kanıt toplayabilir; son değişikliği yapan sistemin kurallarını atlayamamalıdır.

Nereden başlamalı?

Şirketin tamamını bir anda modellemeyin. Yanlış aksiyonun maliyetli olduğu tek bir domain ve iş akışı seçin: müşteri doğrulama, iade, sözleşme yenileme veya erişim onayı.

1. İş alanı sahipleriyle kanonik kavramları ve ekipler arasındaki tanım farklarını belirleyin.
2. Eş anlamlıları, kimlikleri, durumları ve istisnaları açıkça yazın.
3. Kavramları otoriter kaynaklara, güncellik bilgisine ve kanıta bağlayın.
4. Agent’a az sayıda, açık sözleşmeli ve güvenli araç verin.
5. Gerçek sorulardan oluşan bir değerlendirme seti hazırlayın; yanıt kadar kaynak seçimini ve aksiyon kararını da ölçün.
6. İlk aşamada kritik aksiyonları insan onayına sunun; hataları ve müdahale nedenlerini ölçerek otonomiyi artırın.

Bu çalışma çoğu zaman teknik bir projeden önce organizasyonel bir problemi görünür kılar: Satış, finans ve destek aynı “müşteri” kelimesini kullanıyor ama aynı varlık kümesini kastetmiyor olabilir. Agent bu anlaşmazlığı çözmez; yalnızca otomatikleştirir.

Sonuç

LLM’ler dünyaya dair genel bilgiyi getirir. Agent’lar bu bilgiyi araçlar, güncel veriler ve planlama döngüsüyle kullanabilir. Fakat şirketinizin domainlerini, domain kurallarını ve kritik aksiyonların sınırlarını kendiliğinden bilmezler.

Ontology, şirketin kendi dünyasını makinece yorumlanabilir hale getirir: kavramları tanımlar, ilişkileri bağlar, kuralları görünür kılar, doğru kaynağı işaret eder ve agent’ın aksiyonlarını güvenli sistemlere bağlar.

Model sağlayıcınız ve agent çerçeveniz değişebilir. Müşterinin ne olduğu, bir sözleşmenin ne zaman aktif sayıldığı ve hangi işlemi kimin onaylayabileceği ise şirketinizin kalıcı bilgisidir. Güvenilir agent tasarımı, modeli değiştirmekten önce bu bilgiyi açıkça modellemekle başlar.