Bugün işletmelerin büyük çoğunluğu veriye sahip olduğunu düşünüyor, ancak gerçekte sahip oldukları şey anlamlandırılmamış veri yığınlarıdır. ERP, MRP, MES, CRM, e-ticaret ve log sistemleri sürekli veri üretir; fakat bu veriler bir araya gelmediği, anlamlandırılmadığı ve yorumlanmadığı sürece işletmeye gerçek bir katkı sağlamaz. Dijital dönüşümün özü veri toplamak değil, veriden anlam üretmek ve bu anlamı karar mekanizmasına dönüştürmektir. Bu yazıda, bir işletmenin elindeki dağınık veri setlerini nasıl merkezi bir yapıya taşıyacağını, nasıl anlamlandıracağını, neden vektör hale getirmesi gerektiğini, embedding modellerinin ne olduğunu ve neden kritik olduğunu, bu veriyi RAG ve LLM ile nasıl konuşturabileceğini ve tüm bu sürecin SQL Server 2025 ve modern veri platformları ile nasıl mümkün hale geldiğini uçtan uca anlatıyorum.
Bir işletmenin elindeki veri, tek başına hiçbir değer üretmez. ERP sisteminde tutulan satış kayıtları, MRP’deki üretim planları, MES’ten gelen makine verileri, e-ticaret platformundaki müşteri davranışları ya da sistem logları… Bunların her biri kendi içinde doğrudur ancak birlikte anlam üretmez. Çünkü bu sistemler birbirinden bağımsız çalışır. Aynı müşteri farklı sistemlerde farklı kimliklerle yer alır, aynı ürün farklı isimlerle geçer, aynı olay farklı formatlarda kaydedilir. Bu yüzden veriden değer üretmenin ilk adımı veri toplamak değil, veriyi bir araya getirmek ve ilişkilendirmektir.
Bu noktada ETL veya ELT süreçleri devreye girer. Farklı sistemlerdeki veriler çekilir ve merkezi bir yapıya taşınır. ETL yaklaşımında veri önce temizlenir ve dönüştürülür, ardından yüklenir. ELT yaklaşımında ise veri olduğu gibi alınır, merkezi sisteme yüklenir ve dönüşüm işlemleri burada yapılır. Modern veri mimarilerinde ELT daha çok tercih edilir çünkü ham veriyi kaybetmezsin ve gerektiğinde yeniden işleyebilirsin. Bu veriler genellikle bir Data Lake veya Data Warehouse içinde tutulur. Günümüzde bu süreç Microsoft Fabric, Azure Synapse, Snowflake veya BigQuery gibi platformlarla da gerçekleştirilebilir. Ancak kullanılan teknoloji değişse de amaç aynıdır: veriyi merkezi hale getirmek.
Ancak veriyi toplamak ve barındırmak tek başına yeterli değildir. Çünkü veri hala anlaşılabilir değildir. İşte burada semantic layer yani anlam katmanı devreye girer. Semantic layer, farklı sistemlerden gelen verileri ortak bir dilde buluşturur. Aynı müşteriyi tekilleştirir, ürünleri normalize eder, ilişkileri kurar ve veriyi iş birimlerinin anlayabileceği hale getirir. Bu katman Power BI semantic model, dbt veya doğrudan SQL modelleme ile oluşturulabilir. Buradaki kritik nokta kullanılan araç değil, verinin anlam kazanmasıdır.
Bu aşamaya kadar klasik veri dünyasıyla ilerlersin. Ancak burada önemli bir sınır vardır. Klasik veri sistemleri yalnızca tablo formatındaki verilerle çalışır. Oysa işletmelerde gerçek değer çoğu zaman metin tabanlı verilerde gizlidir. Log kayıtları, müşteri yorumları, destek talepleri, operatör notları gibi veriler klasik SQL ile yalnızca kelime bazlı aranabilir. Yani sistem “ne yazıldıysa onu bulur” ama “ne anlatılmak istendiğini” anlayamaz. İşte bu noktada vektör kavramına ihtiyaç duyarız.
Vektör, bir verinin sayısal temsilidir; ancak burada kritik olan verinin kendisini değil, anlamını sayıya dönüştürmektir. Embedding modeli bir metni alır ve onu tek bir sayı yerine yüzlerce sayıdan oluşan bir listeye çevirir. Örneğin bir cümle şu şekilde temsil edilebilir: [0.12, -0.87, 0.45, …]. Bu sayıların her biri modelin öğrendiği bir anlam boyutunu temsil eder. Bu boyutlar bizim doğrudan anlayabileceğimiz başlıklar değildir ancak model için bu sayılar birlikte cümlenin anlamını oluşturur. Bu yapı çok boyutlu bir uzay olarak düşünülebilir. Her cümle bu uzayda bir noktadır ve anlam olarak birbirine yakın cümleler bu uzayda birbirine yakın konumlanır.
Örneğin “Makine aşırı ısındı” ve “Makine sıcaklık hatası verdi” cümleleri farklı kelimeler içerir ama embedding modeli bu iki cümleyi birbirine çok yakın noktalar olarak konumlandırır. Çünkü model bu iki ifadenin aynı durumu anlattığını öğrenmiştir. Bu sayede artık sistem kelimeye değil, anlama bakar.
Embedding modellerine ihtiyaç duyulmasının sebebi tam olarak budur. Modern veri problemleri eşleşme değil, benzerlik problemidir. Kullanıcılar aynı veriyi değil, benzer durumu bulmak ister. Eğer embedding kullanılmazsa sistem sadece birebir eşleşme yapar. Bu durumda “error” kelimesini bulur ama “failure” kelimesini kaçırır. Aynı hatanın farklı yazımlarını ilişkilendiremez. Bu da özellikle log analizi, müşteri deneyimi ve üretim hatası gibi alanlarda ciddi veri kayıplarına neden olur.
Embedding kullanılmadığında ortaya çıkan en kritik problem şudur: verinin büyük bir kısmı aslında sistem tarafından hiç görülmez. Çünkü anlam yakalanamaz. Bu da işletmenin sahip olduğu verinin gerçek potansiyelini kullanamaması anlamına gelir. Veri vardır ama içgörü yoktur.
Embedding üretildikten sonra bu verilerin saklanması ve hızlı şekilde sorgulanması gerekir. Klasik veritabanları bu iş için uygun değildir çünkü milyonlarca vektör arasında benzerlik araması yapmak matematiksel olarak farklı bir problemdir. Bu yüzden vector database kullanılır. Vector database’ler bir sorguya en yakın anlamdaki veriyi bulur. Bu sayede sistem “aynı veriyi” değil, “en alakalı veriyi” getirir.
Eskiden bu ihtiyaç için Pinecone, Weaviate, Milvus gibi ayrı sistemler kullanılırdı. Ancak günümüzde bu yetenek doğrudan veritabanlarının içine girmeye başlamıştır. Özellikle SQL Server 2025 ile birlikte vektör veri tipleri ve AI destekli özellikler doğrudan veritabanı seviyesinde kullanılabilir hale gelmektedir. Bu, veriyi farklı sistemlere taşımadan aynı platform içinde hem saklama hem analiz hem de anlamlandırma yapılabileceği anlamına gelir. PostgreSQL tarafında pgvector, MongoDB tarafında vector search gibi yaklaşımlar da benzer şekilde bu dönüşümü desteklemektedir. Yani veritabanları artık sadece veri saklayan sistemler değil, anlam işleyen sistemler haline gelmektedir.
Bu noktada sistem artık doğru veriyi bulabilir hale gelir. Ancak kullanıcı hala değer üretmez. Çünkü kullanıcı veri görmek istemez, cevap ister. İşte burada RAG yani Retrieval-Augmented Generation devreye girer. RAG, kullanıcıdan gelen soruya göre en ilgili veriyi bulur ve bu veriyi cevap üretiminde kullanır. Kullanıcı bir soru sorduğunda bu soru vektöre çevrilir, vector database içinde en alakalı veriler bulunur ve bu veriler dil modeline gönderilir. Böylece sistem bağlama uygun veri ile çalışır.
Ancak RAG tek başına yeterli değildir çünkü RAG sadece veri getirir, yorum yapmaz. İşte burada LLM yani Large Language Model devreye girer. LLM, getirilen veriyi analiz eder, özetler, ilişkilendirir ve doğal dilde anlamlı bir cevap üretir. Yani sistem artık veri sunmaz, yorum yapar. RAG doğru veriyi bulur, LLM bu veriyi anlamlı bir cevaba dönüştürür. Bu ikisi birlikte çalıştığında sistem veriyi getirir, anlar, yorumlar ve kullanıcıya doğrudan cevap verir.
Bu yapı kurulduğunda işletme içinde çok kritik bir değişim yaşanır. Kullanıcılar artık dashboard okumak zorunda kalmaz, SQL yazmaz, teknik analiz yapmak zorunda kalmaz. Bunun yerine doğal dilde soru sorar ve doğrudan cevap alır. Bu da veri kullanımını teknik ekiplerden çıkarıp tüm organizasyona yayar.
Ancak bu dönüşüm yapılmadığında işletmeler ciddi risklerle karşı karşıya kalır. Verinin dağınık olduğu yapılarda kararlar eksik ya da yanlış bilgiye dayanır. Aynı veri farklı sistemlerde farklı sonuçlar üretir. Embedding ve vektör katmanı olmayan bir sistem, verinin büyük kısmını hiç görmüyor demektir. Bu da rekabet avantajının kaybedilmesine neden olur. Ayrıca bilgi kişilerde kalır, sistemde değil. Bu da sürdürülebilirliği ciddi şekilde riske atar.
Sonuç olarak veriden değer üretmek tek bir teknoloji ile çözülen bir problem değildir. Bu bir zincirdir ve her halkası zorunludur. Veriyi toplamazsan hiçbir şey yapamazsın, anlamlandırmazsan yanlış yorumlarsın, embedding kullanmazsan verinin anlamını yakalayamazsın, vektör yapmazsan benzerlikleri göremezsin. Ancak tüm bunları yapsan bile, eğer bu veriyi insanın anlayacağı bir forma dönüştüremezsen yine değer üretemezsin. RAG doğru veriyi bulur, LLM ise bu veriyi yorumlayarak cevap üretir. Bu ikisi birlikte çalıştığında sistem sadece veri gösteren bir yapı olmaktan çıkar, aktif olarak karar üreten bir yapıya dönüşür.
DMC Bilgi Teknolojileri olarak biz bu yolculukta yalnızca bir teknoloji sağlayıcı değil, sürecin tamamında sizinle birlikte ilerleyen bir iş ortağıyız. Verinin toplanmasından anlamlandırılmasına, embedding ve vektör mimarisinin kurulmasından SQL Server 2025 ve diğer modern veri platformları ile AI entegrasyonuna kadar tüm adımları birlikte tasarlıyor, birlikte kuruyor ve birlikte işletiyoruz. Amacımız sadece bir sistem kurmak değil; sizin verinizin, sizin sistemleriniz üzerinde anlam kazanmasını ve sizin için konuşur hale gelmesini sağlamak. Çünkü inanıyoruz ki doğru kurulan bir veri mimarisi, sadece teknik bir yatırım değil, doğrudan iş değerine dönüşen stratejik bir güçtür.