Bulut Bilişim

Google Meet, Slack ve RAG ile Toplantı Hafızası Kurmak

Şöyle söyleyeyim, Toplantılar bitiyor, kararlar uçup gidiyor… Tanıdık geldi mi? Bana çok geliyor, inanın. Geçen ay İstanbul’da bir ürün ekibiyle yaptığım görüşmede herkes “o maddeyi konuşmuştuk ya” deyip duruyordu — ama kimsenin elinde sağlam bir kayıt yoktu. Yok. İşin aslı şu ki şirketlerin büyük çoğunluğu toplantıyı yapıyor, evet, güzel güzel yapıyor,. Toplantının içindeki bilgiyi gerçekten saklayamıyor bir türlü.

Açık konuşayım, Yazının çıkış noktası da tam burası (buna dikkat edin). Japonya merkezli airCloset’in CTO’su Ryosuke Tsuji’nin anlattığı sistem, Google Meet kayıtlarını. Dökümlerini Slack’e taşıyıp üstüne bir de RAG tabanlı arama katmanı ekliyor — yani sadece “kaydı izleyelim” demiyor, “geçen hafta ne konuşmuştuk?” sorusuna doğrudan, düzgünce cevap veriyor. Açık konuşayım: kağıt üstünde basit duruyor bu fikir, ama pratikte bayağı iş görüyor.

Ben bu tarz sistemleri ilk kez 2023’te kendi küçük ekibimde denemiştim. O zamanlar Notion’a not düşüyoruz diye sevinmiştik — sevinmiştik ya, iki ay geçince notların yarısı eskimiş, kararlar ise Slack içinde kaybolmuş. Buradaki fark şu: otomasyon varsa disiplin zorunluluğu azalıyor. İnsanlara “not alın” demek yerine sistem kendi işini yapıyor. Bu kadar basit, ama etkisi çok farklı.

💡 Bilgi: Bu tip sistemlerin en büyük artısı hız değil, hafıza yaratmasıdır. Toplantı bittikten sonra bilgi kaybını azaltır, ekipler aynı konuyu defalarca konuşmak zorunda kalmaz.

Neden böyle bir sisteme ihtiyaç var?

Toplantılar garip bir şeydir. Text tabanlı iletişime göre çok daha hızlı işliyor. Arkasında çoğu zaman zayıf bir iz bırakıyor — bir karar beş dakikada alınıyor, sonra o kararın gerekçesi üç hafta sonra kimsenin aklında kalmıyor, kimse hatırlamıyor. Ben bunu özellikle kurumsal projelerde gördüm; ekip büyüdükçe sözlü bilgi neredeyse buharlaşıyor, uçup gidiyor.

Bir dakika — bununla bitmedi.

Dur, şunu da ekleyeyim. Sorun sadece unutmak değil. Aynı tartışmayı tekrar tekrar yapmak da ciddi maliyet yaratıyor, hem zaman hem enerji açısından — özellikle ürün, satış ve operasyon ekipleri arasında sık toplantı varsa, herkes farklı yerden hatırlıyor ve sonunda “biz bunu konuşmuştuk” cümlesi havada asılı kalıyor. Kimse sorumluluk alamıyor. Çünkü zaten ortada somut bir şey yok.

Tsuji’nin anlattığı yaklaşım tam burada güzel bir boşluğu dolduruyor. Toplantıyı otomatik olarak kayıt altına alıp Slack’e taşıdığı için bilgi tek bir yerde toplanıyor, dağılmıyor — itiraf edeyim, beklentimin üstündeydi —. Hatta daha önemlisi — ve bence asıl can alıcı nokta bu — bu içerik aranabilir hale geliyor. Yani kayıt klasörlerinde kaybolup boğulmak yerine doğal dille soru sorabiliyorsunuz. Sade ama etkili.

Klasik yöntem neden yetmiyor?

Not almak iyi hoş. Ama insan faktörü var. Bazen biri toplantıya yetişemiyor, bazen notlar fazla kısa kalıyor, bazen de hayati detaylar gözden kaçıyor. Kayıt almak ise çözümün yalnızca yarısı — çünkü kayıt var diye o videoyu açıp 47 dakika izlemek istemiyorsunuz. Kim ister ki?

İşte tam burada arama katmanı devreye giriyor. Toplantıyı depolamak başka şeydir, içinden anlam çıkarmak başka (bizzat test ettim). RAG tam da bu aradaki boşluğu kapatmaya çalışıyor.

Sistemin omurgası nasıl kurulmuş?

Hani, Sistem dört ana parçaya dayanıyor gibi düşünün: toplantıyı kolay başlatma, toplantı bitince otomatik bildirim gönderme, erişim izinlerini düzgün dağıtma. Tüm içeriği semantik olarak arama. Sadece teknik değil, operasyonel akışı da çözüyor yani — bu önemli bir detay.

Bileşen Ne yapıyor? Neden önemli?
Google Calendar + Chrome eklentisi Tek tıkla Meet oluşturuyor Süreç sürtünmesini azaltıyor
Slack entegrasyonu Toplantı bitince kanala haber veriyor Ekip anında haberdar oluyor
Otomatik izin yönetimi Kayıtlara doğru kişilerin erişmesini sağlıyor Güvenlik ve kullanım dengesi kuruyor
RAG arama katmanı Dökümler ve ekran paylaşımlarını sorgulanabilir yapıyor Bilgi mezarlığını canlı araca çeviriyor

İnanın, Bana sorarsanız en hayati nokta izin yönetimi. Çünkü böyle sistemlerde veri toplamak kolaydır; asıl dert doğru kişiye doğru erişimi vermektir. Küçük startup’ta bunu elle idare edebilirsiniz, tamam, ama enterprise tarafta işler karışır — departmanlar ayrı, hassasiyet ayrı, onay zinciri ayrı… Hepsini ayrı ayrı düşünmek gerekiyor (en azından benim deneyimim böyle)

Editör masasında bu haberi görünce ilk düşündüğüm şey şuydu: “Bu sistem aslında toplantı yazılımından çok kurumsal hafızaya benziyor.” Ve evet, bence de öyle. Tam olarak öyle. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.

Kullanıcı akışı neden önemli?

Kullanıcı akışı pürüzsüz olmazsa kimse sistemi kullanmaz — bunu defalarca gördüm. Tsuji’nin anlattığı senaryoda takvim etkinliği içinde özel bir buton görüyorsunuz. Oradan Meet oluşturuyorsunuz; ardından kanal seçiyorsunuz; link takvime düşüyor, bitti. Hepsi bu kadar gibi görünüyor ama esas mesele tam burada zaten: kullanıcı ekstra iş yapmıyor, sisteme ekstra düşünce harcamıyor.

Bash öğrenmek için tarayıcıda uygulama fikrini ilk duyduğumda da benzer hissetmiştim — mantık basit görünür. Deneyim kötü olursa proje ölür gider. Aynı durum burada da geçerli. Aynen. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.

Toplantı zekâsını değerli yapan şey sadece transkript değil; transkriptin doğru anda doğru insana ulaşmasıdır.

RAG kısmı neden oyunu değiştiriyor?

Şimdi gelelim işin biraz daha ilginç tarafına. RAG olmadan bu sistem sadece iyi organize edilmiş bir arşiv olurdu — fena değil, ama yeterli değil. RAG ile birlikte ise soru-cevap makinesine dönüşüyor, — ki bu tartışılır — işte bu fark büyük. Mesela Slack botuna “Geçen hafta konuşulan teslim tarihi neydi?” diye sorabiliyorsunuz ve model dökümlerden cevabı çekip getiriyor. Sormak yeterli, başka bir şey yapmıyorsunuz. Bu konuyla ilgili Claude Word’e Geldi: Yan Panelde Akıllı Düzenleme Dönemi yazımıza da göz atmanızı tavsiye ederim.

Açıkçası bu kısım beni en çok etkileyen bölüm oldu. Klasik arama artık (söylemesi ayıp) yetmiyor çünkü — anahtar kelime eşleştirme sizi bazen yarı yolda bırakır, hani tam aradığınızı bulamadan dönersiniz; anlam üzerinden bulma işi ise bambaşka bir rahatlık veriyor. Denemediyseniz farkı anlatmak zor.

Ekran paylaşımı niye önemli?

Tsuji’nin sistemi yalnızca ses dökümüne yaslanmıyor; ekran paylaşımı da analiz ediliyor. Bu ufak detay aslında büyük fark yaratıyor, çünkü bazı kararlar sözle değil görüntüyle şekilleniyor — örneğin taslak fiyat tablosu ya da ürün yol haritasındaki ufacık bir değişiklik gibi şeyler, bunlar söze gelmeden ekranda belirleniyor.

Ne yalan söyleyeyim, Bunu geçen yıl Ankara’daki bir danışmanlık projesinde bizzat gördüm: toplantıda söylenen şey ile paylaşılan slayttaki rakam birbirinden farklıydı ve herkes sözlü kısmı hatırlarken görseldeki can alıcı sayı kaçmıştı. Evet. Tam bir küçük kaos. İnternetin Bağışıklık Sistemi: AI Güvenlikte Yeni Oyun yazımızda bu konuya da değinmiştik.

Küçük ekipte başka çalışır, büyük şirkette başka

Küçük startup’ta böylesi bir sistem genelde rahat nefes aldırır. Süreçler az karmaşık, insanlar birbirini tanıyor; izin modeli de nispeten sade kalıyor. Bir Slack kanalıyla her şeyi bağlayabilirsiniz mesela — gayet yeterli olabilir, ciddi söylüyorum. Bash Öğrenmek İçin Tarayıcıda Bir Uygulama: Fikir Güzel mi? yazımızda bu konuya da değinmiştik.

Lafı gevelemeden söyleyeyim: enterprise seviyede aynı yaklaşım yetmezse patlar gider. Çünkü orada hukuk var, güvenlik var, bölgesel veri saklama talepleri var, hatta bazen sendika hassasiyeti bile çıkıyor karşınıza.

  • Küçük startup: Hız öncelikli olur, minimum entegrasyon yeterli.
  • Büyüyen scale-up: Arama kalitesi ve rol tabanlı erişim önem kazanır.
  • Kurumsal yapı: Denetim izi, veri politikası ve uyumluluk öne çıkar.

Neyse uzatmayayım. Benim gözlemim şu: küçük ekipler önce verimi kazanmak isterken büyük kurumlar önce riski kontrol etmek istiyor. İkisi de haklı, ama ihtiyaçlar gerçekten çok farklı.

Dürüst yorum: Böyle sistemlerin demo’su hep parlak görünür; gerçek hayatta ise kalite kontrolü yapılmazsa transkript çöplüğe döner.
Yani teknoloji güzel ama bakım işi biraz can sıkıcı olabilir.

Tasarımda sağlam taraflar ve açıkta kalan yerler

İlginç olan şu ki, Bence en güçlü taraf otomasyonun uçtan uca düşünülmüş olması. Birçok ekip sadece transkripti alıp bırakıyor — iş bitti, arşivlendi, tamam. Ama burada dağıtım kanalı da düşünülmüş, bu önemli. Bilgi üretmek kadar bilgiyi dolaşıma sokmak da meseledir. Mantıklı değil mi? Slack’e düşmeyen içerik çoğu zaman yaşamaz, kullanılmaz, öylece orada durur.

Peki eksikleri yok mu?

Var tabi. En başta doğruluk problemi geliyor — konuşmayı yazıya çevirmek tek başına yeterli değil; özellikle jargon yoğun ortamlarda hata payı can sıkabilir, bazen kritik bir terimi yanlış yakalıyor sistem ve oradan saçma bir sonuç çıkıyor (ben de ilk duyduğumda şaşırmıştım). Bir de gizlilik tarafı var. Kimin neyi görebileceği net değilse sistem faydadan çok yük getirir, buna eminim.

Bence, Bana göre beklediğimden az kalan nokta tam burada aslında: her şeyi otomatikleştirirken insan kontrolünü tamamen silmek riskli. Çok riskli. O yüzden iyi tasarlanmış onay mekanizmaları şart, vazgeçilmez.

// Basit akış örneği
calendarEvent.created -> meetProvisioned
meetEnded -> transcriptGenerated
transcriptReady -> slackNotify(channel)
accessGranted -> participants + channelMembers + invitees
ragIndex.updated -> semanticSearchEnabled

Sıkça Sorulan Sorular

Böyle bir sistem küçük ekipler için uygun mu?

Evet, hatta çoğu zaman en hızlı faydayı küçük ekipler görüyor. Toplantıları düzenlemek kolaylaşıyor ve bilgi kaybı azalıyor.

RAG olmadan bu çözüm işe yarar mı?

Kısmen yarar ama asıl güç azalırdı. RAG olmadan elinizde aranabilir bir arşiv olurdu; cevap veren asistan hissi zayıflardı.

Slack entegrasyonu neden önemli?

Çünkü insanlar zaten gün boyu Slack içinde yaşıyor. Bilgiyi oraya taşımak kullanım oranını ciddi biçimde artırır.

Ekran paylaşımı analizi gerçekten gerekli mi?

Evet, bazı kararlar konuşmadan çok görsel üzerinden anlaşılır. Mesela ürün planlama ve finans tablolarında fark yaratır.Kaynaklar жәne İleri Okuma

Google Meet Resmi Sayfası</?>

Aşkın KILIÇ

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

Bu içerik işinize yaradı mı?

Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.

Haftalık Bülten

Her pazar özenle seçilmiş teknoloji yazıları doğrudan e-postanıza gelsin.

← Onceki Yazi
Motorola Razr 70 Sızdı: Katlanabilirde Neler Değişiyor?
Sonraki Yazi →
3 Katmanlı Design Token Neden Önemli?

Yorum Yaz

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Haftalık Bülten

Azure, DevOps ve Yapay Zeka dünyasındaki en güncel içerikleri her hafta doğrudan e-postanıza alın.

Spam yok. İstediğiniz zaman iptal edebilirsiniz.
📱
Uygulamayı Yükle Ana ekrana ekle, çevrimdışı oku
Kategoriler
Ara
Paylaş
İçindekiler
← Motorola Razr 70 Sızdı: Katlan...
3 Katmanlı Design Token Neden ... →
📩

Gitmeden önce!

Her pazar özenle seçilmiş teknoloji yazıları ve AI haberleri doğrudan e-postanıza gelsin. Ücretsiz, spam yok.

🔒 Bilgileriniz güvende. İstediğiniz zaman ayrılabilirsiniz.

📬 Haftalık bülten: Teknoloji + AI haberleri