Kurumsal Sistemleri Yapay Zekâya Bağlamak: Senkronizasyon mu, Canlı Erişim mi?

Bir kurum “SharePoint'i, SAP'yi veya Salesforce'u yapay zekâya bağlamak” istediğinde teknik olarak üç farklı ihtiyaçtan söz ediyor olabilir:

1. İçeriği bilgi tabanına alıp semantik olarak aramak
2. Görev anında güncel kaydı kaynağından okumak
3. Hedef sistemde kontrollü bir işlem yapmak

Bu ihtiyaçları tek bir “connector” kavramında toplamak; güncellik, yetki ve veri yaşam döngüsü sorunlarını gizler. Doğru mimari çoğu zaman senkronizasyon ve canlı erişimin birlikte kullanıldığı hibrit modeldir.

Üç bağlantı modeli

Aynı ürün birden fazla modelde bulunabilir. Örneğin Salesforce kayıtları Knowledge Hub'a senkronize edilebilir, workflow içinde canlı aranabilir veya agent'a dar bir müşteri arama aracı olarak sunulabilir. Bunlar aynı veri erişim biçimi değildir.

Senkronizasyon nasıl çalışır?

Senkronizasyonda kaynak içerik belirli aralıklarla veya olayla alınır, işlenir ve arama için indekslenir.

Kaynak
  → belge/kayıt listeleme
  → değişiklik ve silme tespiti
  → içerik alma
  → ayrıştırma ve chunking
  → metadata + erişim kapsamı
  → embedding
  → indeks

Kullanıcı soru sorduğunda kaynak sisteme gitmek yerine indeks, yetki filtresiyle aranır. Model yalnızca ilgili parçaları ve kaynak bilgisini alır.

Güçlü yönleri

• Büyük belge koleksiyonunda hızlı semantik arama
• Kaynak geçici olarak kapalıyken çalışma
• Birden fazla kaynağı ortak bilgi alanında birleştirme
• Belge parçalarını kaynak ve metadata ile sunma
• Sorgu başına kaynak API maliyetini azaltma
• Tekrarlanan sorularda tutarlı gecikme

Maliyetleri ve riskleri

• İçeriğin kontrollü bir kopyası oluşur.
• Güncellik senkronizasyon aralığına bağlıdır.
• Kaynak izinlerinin indeks katmanına taşınması gerekir.
• Silinen veya yetkisi kaldırılan içerik hızla yansıtılmalıdır.
• Format ayrıştırma, chunking ve embedding kalitesi yönetilmelidir.
• Büyük değişikliklerde yeniden indeksleme maliyeti doğar.

Senkronizasyon, “veri olduğu yerde kalır” modeli değildir. İçerik, arama için işlenmiş biçimde Knowentra'nın yapılandırılmış bilgi ve vektör katmanına alınır. Bunun veri sınıflandırması, saklama ve silme politikası açık olmalıdır.

Canlı erişim nasıl çalışır?

Canlı erişimde workflow veya agent, görev anında hedef sistem API'sini izinli bir araçla çağırır.

Görev
  → kullanıcı ve agent kimliği
  → araç/operasyon yetkisi
  → credential çözümleme
  → kaynak API çağrısı
  → response şeması ve veri politikası
  → model bağlamı veya workflow sonucu

Güçlü yönleri

• İşlem anındaki en güncel kayıt
• Kaynak sistemin kendi alan/nesne izinlerinden yararlanma
• Gereksiz kalıcı kopyayı azaltma
• Yapılandırılmış sorgu ve yazma işlemleri
• Kaynak audit kayıtlarıyla daha güçlü ilişki

Maliyetleri ve riskleri

• Her görev kaynak sistem erişilebilirliğine bağlıdır.
• API gecikmesi ve rate limit kullanıcı deneyimini etkiler.
• Kimlik ve token yenileme her çağrıda doğru çalışmalıdır.
• Tool output prompt injection veya hassas veri içerebilir.
• Karmaşık araştırma çok sayıda API çağrısı üretebilir.
• Kaynak şema/API değişikliği akışı anında bozabilir.

Canlı erişim semantik belge aramasının yerini doğrudan tutmaz. Kullanıcı “son üç yıldaki tüm bakım raporlarında aynı arıza örüntüsü var mı?” diye soruyorsa her raporu görev anında çekmek yavaş, pahalı ve rate limit açısından riskli olabilir.

Kararı belirleyen sekiz boyut

1. Güncellik

Bilgi saniyeler içinde değişiyorsa canlı erişim güçlüdür. Politika, prosedür ve kılavuz gibi daha yavaş değişen içerik senkronizasyon için uygundur.

“Günlük güncel” yeterliyse gece senkronizasyonu; “işlem anı” gerekiyorsa canlı sorgu veya event-driven güncelleme düşünün.

2. Sorgu biçimi

Serbest dilde semantik keşif ve uzun belge bağlamı RAG'a uygundur. Belirli müşteri ID'si, sipariş numarası veya durum filtresiyle kayıt arama canlı API'ye uygundur.

3. Veri hacmi

Binlerce belgeyi her soruda kaynaktan çekmek doğru değildir. Buna karşılık tek bir güncel stok kaydını sürekli indekslemek gereksiz olabilir.

4. İzin modeli

Kaynak sistem karmaşık ve dinamik alan izinleri uyguluyorsa canlı erişim bunları doğal olarak koruyabilir. Senkronizasyonda erişim listesi veya metadata filtreleri indekse taşınmalı ve değişikliklerle güncellenmelidir.

5. Kaynak dayanıklılığı

Kritik bilgi, kaynak bakımdayken de gerekli mi? Senkronize indeks okuma dayanıklılığı sağlar. Canlı erişim için timeout, circuit breaker ve güvenli fallback gerekir.

6. Veri yerleşimi

Kalıcı kopya oluşturmak mevzuat veya kurum politikası nedeniyle uygun değilse canlı erişim tercih edilebilir. Ancak canlı çağrı sonucu model prompt'una, loga veya geçici cache'e giriyorsa veri yine işlenir; “kopya yok” ifadesi bütün veri akışı incelenmeden kullanılmamalıdır.

7. Maliyet ve performans

Senkronizasyon toplu işleme, embedding ve depolama maliyeti üretir. Canlı erişim ise her sorguda API, ağ ve kaynak sistem yükü üretir. Sorgu sıklığı ve güncelleme oranı birlikte hesaplanmalıdır.

8. İşlem ihtiyacı

RAG indeksi dış sistemde işlem yapmaz. Kayıt oluşturma, güncelleme, bildirim veya onay için workflow entegrasyonu ya da agent aracı gerekir.

Hızlı karar matrisi

Hibrit mimari desenleri

Desen 1 — Politika + güncel kayıt

İnsan kaynakları politikaları ve izin prosedürleri Knowledge Hub'a senkronize edilir. Çalışanın kalan izin günü görev anında HR sisteminden canlı alınır. Model kaynaklı politika açıklamasıyla güncel bakiyeyi birlikte sunar.

Desen 2 — Ürün bilgisi + stok

Ürün kılavuzları, teknik özellikler ve sık sorulan sorular indekslenir. Fiyat ve stok bilgisi ERP/e-ticaret sisteminden canlı sorgulanır.

Desen 3 — Geçmiş vakalar + açık talep

Çözülmüş destek talepleri ve knowledge-base makaleleri semantik aramaya alınır. Kullanıcının açık talebi, SLA'sı ve son yorumları ServiceNow veya Zendesk'ten canlı okunur.

Desen 4 — Toplantı hafızası + aksiyon

Toplantı transcript ve özetleri senkronize edilir. Agent kaynaklardan alınan kararı bulur; onay sonrası Jira veya Linear'da canlı görev oluşturur.

Desen 5 — Bakım bilgisi + iş emri

Kılavuzlar ve geçmiş bakım raporları indekslenir. Aktif sensör durumu, parça stoğu ve iş emri CMMS/MES sisteminden canlı alınır; yeni iş emri workflow onayıyla açılır.

Senkronizasyon tasarımında kritik ayrıntılar

Tam ve artımlı senkronizasyon

Tam senkronizasyon bütün kapsamı yeniden tarar. Basittir ama büyük kaynaklarda pahalıdır. Artımlı senkronizasyon yalnızca son çalışmadan sonra değişen kayıtları ister; kaynak API'nin güvenilir güncelleme zamanı, cursor veya delta desteğine bağlıdır.

Artımlı destek olsa bile periyodik bütünlük taraması yararlı olabilir. Kaçan webhook, saat farkı veya kaynak bug'ı indeks drift'i oluşturabilir.

Değişiklik tespiti

Yalnızca updated_at alanına güvenmek yerine içerik hash'i tutulabilir. Aynı içerik yeniden işlenmez; gerçekten değişen belge tekrar chunk ve embedding sürecine girer.

Silme ve erişim kaldırma

En kritik yaşam döngüsü olayıdır. Kaynakta silinen veya kullanıcının erişemediği belge RAG indeksinde aktif kalmamalıdır.

İki yaklaşım:

• Kaynağın deletion/delta olayını takip etmek
• Tam envanter taramasında artık görünmeyen kaydı silmek

Silme işlemi chunk, embedding, cache ve türetilmiş özetleri kapsamalıdır.

Hata görünürlüğü

Dosya çok büyük, format desteklenmiyor veya API yetkisi yetersizse içerik sessizce atlanmamalı; “başarısız belge” olarak sebebiyle görünmelidir. Aksi halde kullanıcı indeksin eksiksiz olduğunu varsayar.

Canlı erişim tasarımında kritik ayrıntılar

Kullanıcı mı servis hesabı mı?

Kullanıcı adına OAuth, kaynak izinlerini ve audit'i korur. Servis hesabı zamanlanmış süreçler için uygundur; fakat dar kaynak ve operasyon kapsamına sahip olmalıdır.

Cache kullanılır mı?

Kısa süreli cache gecikme ve rate limit'i azaltabilir. Ancak:

• Veri sınıfı
• Kullanıcı/tenant kapsamı
• TTL
• İptal ve güncelleme
• Şifreleme

tanımlanmadan cache, görünmez bir senkronizasyon katmanına dönüşür.

Timeout ve circuit breaker

Kaynak yanıt vermiyorsa agent sonsuza kadar beklememelidir. Timeout sonrası:

• Güvenli hata mesajı
• Varsa son doğrulanmış bilgi ve tarihi
• Retry veya insan kuyruğu
• Circuit breaker ile kaynağı geçici koruma

uygulanabilir. Eski bilgi gösteriliyorsa “güncel” gibi sunulmamalıdır.

Yazma işlemleri

Canlı erişim yazma yeteneği içeriyorsa şema, idempotency, onay, önceki/sonraki değer ve telafi planı gerekir. “Kayıt oku” ile “kayıt değiştir” aynı credential veya tool kapsamında toplanmamalıdır.

Event-driven yaklaşım üçüncü seçenek mi?

Webhook veya olay akışı, senkronizasyonun tetiklenme biçimidir; ayrı bir veri kullanım modeli değildir. Kaynak değiştiğinde:

1. Olay imzası doğrulanır.
2. Event ID ile tekrar teslim engellenir.
3. Değişen kayıt kaynaktan alınır.
4. İndeks güncellenir veya ilgili workflow çalışır.

Event-driven güncelleme güncellik aralığını küçültür; yine de kaçan olaylar için reconciliation job gerekir.

Erişim kontrolü iki hatta da aynı ciddiyette olmalı

Senkronize hatta

• Kaynağın ACL veya grup bilgisi metadata'ya taşınır.
• Retrieval, modelden önce yetki filtresi uygular.
• Yetki değişikliği ve kullanıcı kapatma hızla yansır.
• Kaynak URL'sine gitmek de yetkili erişim gerektirir.

Canlı hatta

• Kullanıcı, agent ve Space yetkisi kesişir.
• Tool operation bazında allowlist uygulanır.
• Credential görev anında güvenli broker'dan çözülür.
• Response gereksiz alanlardan arındırılır.
• Tool output LLM Secure Gateway kontrolünden geçer.

Bir hattın güvenli olması diğer hattaki açığı kapatmaz. Hibrit cevapta her veri parçasının kaynağı ve erişim kararı izlenebilmelidir.

Kaliteyi nasıl ölçersiniz?

Senkronizasyon metrikleri

• Son başarılı çalışma ve gecikme
• Taranan, eklenen, güncellenen, silinen ve başarısız kayıt
• Kaynak–indeks bütünlük farkı
• Ayrıştırma ve embedding hatası
• Yetkisiz retrieval testi
• Kaynak gösterme doğruluğu

Canlı erişim metrikleri

• API gecikmesi ve hata oranı
• Rate-limit tüketimi
• Yetki/şema reddi
• Credential yenileme hatası
• Cache hit ve stale-result oranı
• Tool-call başarı ve telafi oranı

Hibrit sonuç metrikleri

• Yanıtta kullanılan bilginin yaşı
• Senkronize ve canlı kaynakların doğru birleşimi
• Çelişki yakalama oranı
• Kullanıcının kaynak erişimi
• Yanıt sonrası işlemin başarı/audit bağı

Mimari seçim şablonu

Her veri alanı için şu kaydı oluşturun:

Üretim kontrol listesi

• Bilgi connector'ü ile workflow entegrasyonu ayrıldı mı?
• Güncellik gereksinimi ölçülebilir tanımlandı mı?
• Kalıcı kopya ve canlı sonuç için veri politikası var mı?
• Kaynak izinleri her iki hatta da uygulanıyor mu?
• Güncelleme, silme ve erişim kaldırma test edildi mi?
• Artımlı sync kaçırırsa reconciliation çalışıyor mu?
• Canlı çağrıda timeout, rate limit ve circuit breaker var mı?
• Cache kullanıcı/tenant bazında izole ve süreli mi?
• Yazma araçları okuma araçlarından ayrıldı mı?
• Hibrit cevap her bilginin kaynağını ve yaşını gösteriyor mu?
• Kaynak kapalıyken fallback kullanıcıyı yanıltmıyor mu?
• Teknik ve iş metrikleri birlikte izleniyor mu?

Sonuç

Senkronizasyon ile canlı erişim birbirinin alternatifi değil, farklı veri özelliklerine verilen iki cevaptır. Senkronizasyon kurumsal hafızayı hızlı ve aranabilir yapar. Canlı erişim güncel kaydı ve işlem yeteneğini kaynağında tutar.

Knowentra'da Knowledge Hub connector'leri bilgi yaşam döngüsünü; workflow entegrasyonları ve agent araçları ise görev anındaki okuma/yazma işlemlerini yönetir. LLM Secure Gateway, kimlik ve audit katmanı iki yolu ortak güvenlik zincirinde birleştirir.

Mevcut katalog için Desteklenen Entegrasyonlar, bilgi hattı için RAG Nasıl Çalışır? sayfalarını inceleyebilirsiniz.