Türkçe, İngilizceye kıyasla belirgin sayıda daha fazla token harcar.
Aynı anlamı veya bilgiyi aktaran bir metinde Türkçe, modelin sözlük (tokenizer) yapısına bağlı olarak İngilizceye göre genellikle 1.4x ile 2.5x kat (%40 - %150 daha fazla) token tüketir. API fiyatlandırması doğrudan token adedi üzerinden hesaplandığı için bu durum hem girdi (input/encode) hem de çıktı (output/decode) maliyetlerini doğrudan yükseltir.
Kişi, yer veya kurum adlarını tespit eden Varlık İsmi Tanıma (NER) sistemleri, Türkçede İngilizceye kıyasla genellikle daha düşük yakalama (recall) performansına sahiptir.
Özel isimlerin hal, iyelik ve türetim ekleri alarak sürekli değişen yüzey formlarına bürünmesi ("Ankara’ya", "Ahmet’siz"), özellikle gayriresmî metinlerde kesme işaretinin ihmal edilmesiyle birleştiğinde modelin kök varlığı tanımasını zorlaştırır. İkinci olarak; Deniz, Gül, Kaya, Barış, Aydın gibi birçok Türkçe özel ismin aynı zamanda yaygın birer cins isim, sıfat veya fiil kökü olması, özellikle cümle başındaki zorunlu büyük harf kullanımıyla birleştiğinde, ciddi bir sözcüksel belirsizlik (lexical ambiguity) yaratır. Dahası, alt kelime parçalayıcıların (subword tokenizers) ek almış özel isimleri çok sayıda ufak parçaya bölerek sınır tespitini (boundary detection / BIO tagging) zorlaştırması ve Türkçenin serbest söz dizimi nedeniyle bağlamsal konum ipuçlarının İngilizcedeki kadar katı kurallara dayanmaması, NER modellerinin varlıkları doğru sınıflandırması için gerekli işlem miktarını arttırır.
Birebir aynı RAG mimarisi kullanıldığında, Türkçe doküman işleme sistemlerinde İngilizce benchmark’lara kıyasla %5–10 oranında performans kaybı görülür.
Optimize edilmiş, alan verisi iyi hazırlanmış bir İngilizce RAG sistemi yaklaşık %85–%95 doğruluk seviyelerine ulaşabilirken; standart çok dilli embedding ve üretici modellerle, Türkçeye özel uyarlama yapılmadan kurulan Türkçe RAG sistemleri çoğu temel senaryoda yaklaşık %70–%80 bandında kalır. Bu farkı azaltmak için morfoloji duyarlı hibrit arama (morphology-aware hybrid search), Cross-Encoder tabanlı yeniden sıralama (reranking) ve bağlamı koruyan parçalama (contextual chunking) gibi teknikler kullanılır.
Türkçenin sondan eklemeli morfolojik yapısı nedeniyle embedding ve RAG sistemleri, aynı kökün çok sayıda farklı biçimiyle baş etmek zorundadır.
Bir kelime kökü, eklerle çok sayıda farklı forma dönüşebilir: ev → evler→ evlerimiz → evlerimizden. İngilizcede ise aynı anlam, ayrı kelimelerle “from our houses” şeklinde ifade edilir. Bu yapı, aynı kelime kökünün metinlerde çok sayıda farklı yüzey forma (surface form) dağılmasına ve her bir formun görülme sıklığının azalmasına neden olur. Genel yapay zekâ modellerinde uzun veya daha seyrek görülen kelimeler birden fazla tokena parçalanır. Böylece bilgi, daha fazla ve daha düşük frekanslı token arasında dağılır. Ancak Türkçede bu durum, self-attention katmanında anlamsal temsil gücünü zayıflatarak embedding vektör kalitesini düşürür. Bu nedenle ağırlıklı olarak İngilizce veriler ve dil yapısı üzerinde optimize edilmiş tokenization, embedding ve retrieval yaklaşımları, Türkçe RAG sistemlerinde doğrudan aynı bilgi erişim performansını vermez.
Günümüzde kurumsal ERP sistemleri, MCP ve agent entegrasyonlarını desteklemektedir.
SAP; BTP ve OData/CDS servislerini bağlayan MCP köprüleriyle kurumsal omurgasını yapay zekâya açarken Microsoft resmi Dynamics 365 ERP MCP Server altyapısıyla, Oracle OCI Managed MCP sunucularıyla, Odoo ise yerel FastMCP modülleriyle bu ekosisteme dâhil olmaktadır. Bu sayede muhasebe, stok ve satış verileri harici veri havuzlarına kopyalanıp ikinci bir vektör silosunda çoğaltılmak yerine; doğrudan yerleşik ERP, CRM ve finansal kayıt sistemlerinin (System of Record) kendi güvenlik katmanları, yerel API’leri ve yetki matrisleri üzerinden yapay zekâ ajanlarının kullanımına sunulmaktadır.
