Hiçbir LLM Şirketinizi Tanımıyor: Ontology'den Harness'a, Modeli Şirketinizle Tanıştırmak

Bir LLM, eğitim verisinde gördüğü genel kalıpları biliyor: “müşteri”, “sipariş”, “iade” kavramlarının ortalama anlamını. Sizin şirketinizde ise “aktif müşteri” son 90 günde ödeme yapmış hesap olabilir, “iade” ise yalnızca 14 gün içinde ve kargo firması onayıyla açılabilir. Bu kurallar hiçbir eğitim setinde yok ve çoğu zaman şirket içinde de tek bir yerde yazılı değil.

Sonuç tanıdık bir hata türü: model akıcı, kendinden emin ve yanlış cevap veriyor. Bir satış ekibi asistana “geçen çeyrek en çok büyüyen segment hangisi” diye sorduğunda, model tablo isimlerinden tahmin yürütüp yanlış kolonları topluyor. Burada sorun modelin zekâsı değil, bağlamın yokluğu. Daha büyük modele geçmek bu açığı kapatmıyor; açığı kapatan şey şirket bilgisini modelin okuyabileceği, sorgulayabileceği bir yapıya dönüştürmek.

Son 12 ayda konunun iki ayağı da isim ve standart kazandı. Harness tarafında OpenAI 11 Şubat 2026'da “Harness engineering” yazısını yayımladı; Birgitta Böckeler 2 Nisan 2026'da martinfowler.com'da feedforward rehberler ve feedback sensörlerinden oluşan bir çerçeve önerdi; Anthropic da uzun süreli agent'lar için harness tasarımı ve eval üzerine rehberler yayımladı. ETH Zürih'in Şubat 2026'da yayımlanıp Eylül'de güncellenen çalışması, depo düzeyindeki bağlam dosyalarının başarıyı genel olarak artırmadığını ve maliyeti yüzde 20'den fazla yükselttiğini gösterdi; yani “daha uzun talimat” değil, denetlenebilir kural gerekiyor.

Ontology ve semantik katman tarafında Open Semantic Interchange spesifikasyonu 27 Ocak 2026'da ilk sürümüne ulaştı; çalışma grubunda Snowflake, dbt Labs, Databricks, Salesforce ve ThoughtSpot gibi 50'yi aşkın kuruluş var. Proje Temmuz 2026'da Apache Ossie adıyla Apache Incubator'a girdi. Bağlantı katmanında MCP 28 Temmuz 2026 sürümüyle durumsuz hale geldi, Tasks ve Skills over MCP resmi uzantı oldu; dbt Semantic Layer gibi araçlar yönetilen metrikleri MCP sunucusu üzerinden AI istemcilerine açıyor.

Ontology burada akademik anlamından çok pratik bir anlamda kullanılıyor: şirketin dünyasını nesne tipleri (Müşteri, Sipariş, Depo), bunların özellikleri, aralarındaki ilişkiler (Sipariş bir Müşteriye aittir) ve izin verilen eylemler (Siparişi iptal et) olarak tanımlayan model. Palantir'in Foundry platformu bu yaklaşımı popülerleştirdi; dokümantasyonunda nesne ve bağlantıları verinin, eylemleri ise işletmenin “fiilleri” olarak tanımlıyor.

Veritabanı şemasından farkı anlam katmanı taşıması. Şemada orders.status = 3 yazar; ontology'de bunun “kargoya verildi” anlamına geldiği ve bu durumdaki siparişin artık iptal edilemeyeceği yazar. Başlangıç için büyük bir platform gerekmiyor: en kritik 10-15 iş kavramını, tanımlarını ve ilişkilerini tek bir YAML veya JSON Schema dosyasında toplamak bile modele verilen bağlamın kalitesini belirgin şekilde değiştirir. Her kavram için bir cümlelik tanım, bir örnek kayıt ve sık yapılan bir yanlış anlama yazmak iyi bir şablon.

Ontology'nin en hızlı geri dönüş veren parçası metrik tanımları. Bir şirkette “gelir” kelimesi finans ekibi için KDV hariç tahsil edilen tutar, satış ekibi için imzalanan sözleşme bedeli olabilir. Model bu iki tanımı ayırt edemezse her soruya farklı bir sayı döner ve kullanıcı güveni ilk haftada kaybolur.

Semantik katman (semantic layer), metrikleri SQL'den bağımsız, tek kaynaktan tanımlayan katman: “aylık tekrarlayan gelir = aktif aboneliklerin aylık bedel toplamı, deneme hesapları hariç”. dbt Semantic Layer (MetricFlow), Cube, Snowflake Semantic Views ve Databricks Metric Views gibi araçlar bu işi yapıyor; dbt artık AI araçlarının yönetilen metriklere bir MCP sunucusu üzerinden bağlanmasını da destekliyor. Taşınabilirlik tarafında Open Semantic Interchange (OSI) spesifikasyonu Ocak 2026'da ilk sürümüne ulaştı ve Temmuz 2026'da Apache Ossie adıyla Apache Incubator'a girdi; Temmuz 2026 itibarıyla dbt, GoodData, Salesforce ve Polaris için referans dönüştürücüler var, ama yaygın bir ürün içi destek henüz yok. LLM'e ham tablo yerine bu katmanı sorgulayan bir araç vermek text-to-SQL hatalarının önemli bir kısmını ortadan kaldırıyor, çünkü model artık kolon tahmin etmiyor, tanımlı bir metriği çağırıyor. Anti-pattern: modelden doğrudan üretim veritabanında serbest SQL yazmasını beklemek.

Harness, modeli bir işe koşan her şeyin toplamı: sistem talimatları, hangi araçlara erişebildiği, bağlama hangi bilginin ne zaman girdiği, izin sınırları, hata durumunda ne olduğu ve çıktının nasıl değerlendirildiği. Aynı model iki farklı harness içinde bambaşka sonuç verebilir. Böckeler'in Nisan 2026 tarihli yazısı bunu iki tür kontrolle tarif ediyor: ajanı işe başlamadan yönlendiren feedforward rehberler ve hatayı sonradan yakalayan feedback sensörleri.

OpenAI'ın 11 Şubat 2026'da yayımladığı “harness engineering” yazısı bunun somut bir örneği. Ekip, yaklaşık beş ayda elle tek satır yazmadan bir milyon satır civarında kod üreten bir Codex kurulumunu anlatıyor. Başarıyı modele değil ortama bağlıyorlar: kısa bir AGENTS.md dosyası ayrıntılı docs klasörüne harita görevi görüyor, özel linter'lar mimari kuralları zorluyor ve hata mesajlarına düzeltme talimatı yazılıyor. Bu dersi ETH Zürih'in 2026 çalışması da destekliyor: depo düzeyindeki bağlam dosyaları görev başarısını genel olarak artırmıyor, çıkarım maliyetini ise ortalama yüzde 20'den fazla yükseltiyor. Yani talimatı uzatmak yerine kuralları makinenin denetleyebileceği hale getirmek gerekiyor.

Ontology tek başına bir dokümandır; harness'a bağlandığında işe yarar hale gelir. Bağlantının en yaygın yolu araç (tool) tanımları. Model “müşteri ara”, “siparişin durumunu getir”, “iade talebi oluştur” gibi ontology'deki nesne ve eylemlere karşılık gelen araçları çağırır. MCP (Model Context Protocol) bu araçları farklı istemcilere standart bir şekilde sunmanın yaygın yolu oldu; 28 Temmuz 2026 sürümüyle protokol durumsuz (stateless) hale geldi ve Skills over MCP gibi resmi uzantılar eklendi. Araç tasarımında Anthropic'in önerisi az sayıda, amacı net, kısa ve anlamlı sonuç döndüren araçlar yazmak.

İkinci yol bağlam mühendisliği: her istekte tüm ontology'yi değil, soruyla ilgili nesne tanımlarını ve ilişkilerini bağlama koymak. Bir lojistik senaryosunda “İzmir deposundaki geciken sevkiyatlar” sorusu için Depo, Sevkiyat ve Gecikme tanımları yeter; İK nesneleri gereksiz gürültü. Eylemler tarafında ontology izinleri taşımalı: “siparişi iptal et” aracı yalnızca belirli rollerde ve belirli durumlardaki siparişler için çağrılabilir olmalı. İzin kuralı prompt'ta değil, aracın kendisinde yaşamalı. Böylece model yanlış niyetle de çağırsa eylem gerçekleşmez.

Modeli şirketinizle tanıştırıp tanıştırmadığınızı ölçmenin yolu, şirkete özgü bir değerlendirme seti (eval) kurmak. Genel benchmark'lar burada hiçbir şey söylemez. Gerekli olan, gerçek kullanıcı sorularından derlenmiş 50-200 soruluk bir set ve her biri için beklenen cevap ya da beklenen araç çağrısı. Anthropic'in Ocak 2026 tarihli eval rehberi bunu otomatik değerlendiricilerle insan incelemesini birleştirmek, aynı görevi birden çok kez koşup tutarlılığı ölçmek ve transkriptleri okuyup testin gerçekten doğru şeyi ölçtüğünü doğrulamak olarak çerçeveliyor.

Örnek: “Ankara bölgesinde geçen ay iptal edilen sipariş sayısı” sorusunun doğru cevabı belli bir sayı ve doğru yol “sipariş_say” aracını bölge ve durum filtresiyle çağırmak. Her ontology veya prompt değişikliğinden sonra set yeniden çalıştırılır; doğru cevap oranı, doğru araç seçimi oranı ve gereksiz araç çağrısı sayısı izlenir. Anti-pattern: birkaç demo sorusunda iyi çalıştığını görüp üretime almak. Kullanıcılar ilk hafta demo setinde olmayan soruları soracaktır. Gerçek kullanıcı loglarından her hafta beş yeni soru eklemek, seti canlı tutmanın basit bir yolu.