Cerebras şirket içi bilgi tabanını nasıl kurdu

• Slack/kod depoları/dokümantasyon/iç veritabanlarından mevcut konumlarında doğrudan veri toplayan Cerebras Knowledge geliştirildi ve yayına alındı; bu sistem lansmandan 3 ay sonra çalışanlardan/otomasyondan/ajanlardan günde 15.000’den fazla soruyu işlemeye başladı
• Tüm verileri tek bir araca taşımak yerine, ortak şemaya sahip Postgres embedding tablosuna bağlanacak şekilde tasarlandı; toplama/sorgulama/kimlik doğrulama ve yetkilendirme/denetim/analiz katmanları ayrıldı, böylece yeni veri kaynakları kolayca eklenebiliyor
• Slack araması için yalnızca ham metin embedding’i yeterli olmadığından tam metin arama/embedding arama/ters belge sıklığı/zaman sönümleme birlikte kullanılıyor; ayrıca thread özetleri ile önemli tekil mesaj kümeleri ayrı ayrı embedding’e dönüştürülüyor
• Her sorguda LLM önce hangi arama araçlarını kullanacağını planlıyor, ardından sonuçları paralel topluyor ve bunları RRF ile yeniden sıralama modeli üzerinden birleştiriyor; MCP’de ise aynı arama yetenekleri küçük ve kararlı ilkel araçlar olarak doğrudan sunuluyor
• Tüm organizasyonu koşulsuz aramak yerine, Slack kanalları/depolar/doküman alanlarını bir araya getiren proje bazlı arama kapsamı varsayılan olarak atanıyor; böylece her ekip için daha ilgili sonuçlar sağlanıyor

---

Bilginin üretildiği yerden doğrudan toplama

• Cerebras’ın veri merkezi operasyonları/çip tasarımı/donanım/eğitim/çıkarım/cloud platform ekiplerinde her yıl yüzlerce yeni kişi işe başladığı için “X nerede”, “Y konusunda uzman kim”, “Z nedir” gibi sorular tekrar tekrar soruluyordu
• Tüm bilgiyi tek bir platformda kaydetme yaklaşımının gerçek iş akışında iyi çalışmadığına karar verildi
  • Bilgi; doküman öneri düzeltmeleri, Slack thread’leri, GitHub kod referansları, Jira durum metadata’sı gibi, her işe en uygun araçta üretiliyor
  • Her platform, uzun yıllara dayanan ürün geliştirme ve analiz sayesinde belirli alanlara göre optimize edildiği için, insanların kullanım biçimini zorla değiştirmemeyi seçtiler
• Toplama aşamasında her platforma doğrudan bağlanarak mevcut çalışma alışkanlıklarındaki değişim en aza indirildi

Ortak embedding tablosu merkezli mimari

• Bilgi tabanı üç katmandan oluşuyor
  • İç verileri toplayan ve saklayan platform
  • Saklanan verileri sorgulayan platform
  • Kimlik doğrulama/yetkilendirme/denetim/analiz uygulayan katman
• Merkezde, birden çok kaynaktan gelen embedding/ham metin özeti/metadata bilgisini tutan tek bir Postgres tablosu bulunuyor
• Slack thread’leri, kod depoları, doküman sistemleri, netlist’ler ve özel veritabanları aynı embedding satırı arayüzünü kullanıyor
• Her veri kaynağı, verinin tanımını, bağlanma yöntemini ve toplama periyodunu belirliyor; ortak tabloya yazıldığı anda aynı sorgu arayüzünden aranabilir hale geliyor
• Cerebras geliştiricilerinin ayrı bağlayıcılar üretebilmesi için veri arayüzü bilinçli olarak basit tutuluyor

Slack için gereken hibrit arama

• Slack, en güncel mühendislik tartışmalarının geçtiği en önemli veri kaynağıydı
• Ham metne sadece embedding uygulayan vektör aramasıyla tüm ilgili bilgiyi bulmak zordu
  • “evet, tamam” gibi kısa mesajlarla ayrıntılı kernel açıklamaları aynı mesaj biriminde saklanıyor
  • Kısa mesajlar, daha uzun ve ayrıntılı mesajların önüne cosine similarity açısından sık sık geçebiliyor
  • Tekil mesajların anlamı çevresindeki konuşmaya bağlı oluyor
• Her Slack thread’i aynı anda dört şekilde aranıyor
  • Tam metin arama, embedding içinde bulanıklaşan hata dizeleri/flag adları/host adları gibi kesin token’ları buluyor
  • Embedding arama, “manifest sonrası restore duruyor” ile “NFS mount üzerinde checkpoint takılıyor” gibi farklı kelimelerle ifade edilen soru ve cevapları bağlıyor
  • Ters belge sıklığı (IDF), nadir ayar flag’leri içeren kısa mesajların sırasını yükseltip yaygın tepkisel ifadelerin puanını düşürüyor
  • Zaman sönümleme, aynı derecede ilgili cevaplar arasında, eski altyapıyı anlatabilecek geçmiş thread’ler yerine daha yeni thread’leri öne çıkarıyor
• Tek bir puana güvenmek yerine, her arama motorunun ürettiği sıralı liste sorgu anında birleştiriliyor

Socket Mode tabanlı gerçek zamanlı toplama

• Slack botu workspace’e kuruldu ve Socket Mode üzerinden sürekli bir WebSocket bağlantısıyla tüm mesaj olayları alındı
• Böylece Web API tekrar tekrar çağrılmadan gerçek zamanlı güncelleme yapıldı ve rate limit tüketimi azaltıldı
• Bir olay geldiğinde sisteme hemen yanıt veriliyor, kararlı event ID ile tekrarlar ayıklanıyor ve ardından toplama tüketicisinin işlemesi için işaretleniyor
• Yeni mesaj bağımsız olarak saklanmıyor; bunun yerine mesajın ait olduğu tüm thread yeniden getiriliyor
  • Ebeveyn mesaj ve tüm yanıtlar tek bir satır olarak saklanıyor
  • Mevcut thread’e yanıt eklendiğinde ebeveyn/kardeş yanıtlar/katılımcı listesi/son etkinlik zamanı hep birlikte güncelleniyor
• Her Slack kanalı ayrı bir veri kaynağı olarak ele alınıyor; bu sayede olay müdahale kanalları gibi sık değişen kanallar için daha kısa toplama periyotları ayarlanabiliyor

Thread damıtma ve yapılandırma

• Ham Slack metni, Postgres GIN tam metin indeksi sayesinde kaydedilir kaydedilmez anahtar kelime aramasına açılıyor
• Vektör araması için LLM, tüm thread’den şu öğeleri çıkarıyor
  • Bir mühendisin gerçekten aratabileceği tek satırlık soru
  • Kısa özet
  • Çözüm yöntemi
  • İlgili sistemler ve kod referansları
• Çıkarılan öğeler embedding’e dönüştürülüp ortak tabloda saklanıyor; özgün konuşma metni doğrudan embedding’e dönüştürülmüyor
• Deneylerde, thread’ler tutarlı bir biçime normalize edildiğinde doğruluk ciddi ölçüde arttı; ek metadata da anlamsal arama için daha yararlı sinyaller sağladı

Uzun thread’lerde tekil mesajları koruyan Bursting

• Sadece thread düzeyi özet kullanıldığında, uzun konuşmalardaki önemli mesajların kaçırılması sorunu sürüyordu
• Aynı yazarın art arda gönderdiği mesajlar ardışık mesaj kümesi (burst) olarak birleştiriliyor ve thread konusu bağlam olarak başa eklenip ayrı embedding oluşturuluyor
• Böylece thread özetine girmeyen yan tartışmalardaki cevaplar da bağımsız biçimde aranabiliyor
• Düşük sinyalli mesajların veritabanına girmesini önlemek için ağırlıklı sinyal hesaplanıyor ve yalnızca eşik değerini geçen kümeler saklanıyor
  • Tüm derlem içinde IDF’si 4.0 veya daha yüksek olan nadir token’lar içeriyor
  • Birleştirilmiş mesaj uzunluğu en az 200 karakter oluyor
  • En az bir mesajda tepki emojisi bulunuyor ve bu da sosyal ağırlık sağlıyor
• Koşulları sağlayan kümeler, thread düzeyi kayıtlarla birlikte ortak embedding tablosunda saklanıyor

Büyük kod depoları için artımlı embedding

• Claude Code gibi komut satırı araçları yaygınlaştıkça, kod için grep’in yeterli olabileceği düşünüldü; ancak sektör paydaşlarıyla ve Cursor’un büyük kod tabanlarında anlamsal arama sonuçları incelendikten sonra kod embedding’i benimsendi
• Bazı iç depolar 40GB’ı aştığı için, bunların tamamını sürekli yeniden embedding’e dönüştürmenin maliyeti büyük bir sorundu
• Birden çok deneyin ardından, kod tabanı vektörleştirmeye odaklanan açık kaynak doküman embedding çatısı CocoIndex seçildi
• Kod, dile özgü regex sınırları büyük birimden küçük birime doğru uygulanarak bölünüyor
  • Önce sınıf gibi üst seviye sınırlar kullanılıyor
  • Parça çok büyükse yöntem ve daha küçük blok sınırlarına iniliyor
  • Tek bir dosyadan dosya düzeyi/fonksiyon düzeyi gibi farklı ayrıntı seviyelerinde birden çok embedding üretilebiliyor
• CocoIndex, Postgres’te senkronizasyon metadata’sını tuttuğu için her commit’te yalnızca değişen kod parçaları yeniden embedding’e dönüştürülüp dışa aktarılıyor
• Depo sayısı arttıktan sonra onboarding, ekiplerin doğrudan gönderebildiği yapılandırma dosyalarına taşındı ve dosya yolu bazlı izin listesi/engelleme listesi desteği eklendi

Özel veri kaynaklarını bağlama

• Bazı ekipler, mevcut veritabanı bilgilerinin Slack’e ya da doküman sistemlerine taşınmadan da aynı arama arayüzüyle kullanılmasını istiyordu
• Özel kaynaklar birer eklenti betiği olarak ele alındı
  • Ekip, mevcut sistemi okuyup ortak embedding tablosu biçimindeki satırları dışa aktaran küçük bir Python modülünü pull request olarak gönderiyor
  • Buna karşılık gelen veri kaynağı yapılandırması da birlikte ekleniyor
• Paylaşılan veritabanına ortak şemayla yazılması yeterli; böylece veri Slack/kod/dokümanlarla birlikte aranabiliyor ve sistemin geri kalanında ayrıca bir işlem gerekmiyor

Sorgu planlama ve araçların paralel çalıştırılması

• Her soruda LLM önce kısa bir planlama aşaması çalıştırarak hangi araçları ve veri kaynaklarını kullanacağını belirliyor
• Başlıca araçlar şunlar
  • subsystem_index: dosya bazlı LLM özetleri
  • search: Slack/wiki/kod/diğer indeksleri birleştiren ve içeride birleştirme ile yeniden sıralama yapan vektör araması
  • search_slack: doğrudan Slack araması
  • search_code: kaynak depolar için ripgrep
  • recent_prs: soruyla ilgili son pull request’ler
  • who_knows: belirli bir konuda gerçekten uzmanlık göstermiş kişileri arama
• Planlayıcı; proje listesi, proje bazlı veri kaynakları ve her kaynağın cevaplamaya uygun olduğu soru türlerinin sıkıştırılmış açıklamalarını kullanıyor
• Yürütücü, seçilen araçları paralel çağırıyor; sonuçları ortak bir kanıt biçimine normalize edip nihai sentez LLM’ine aktarıyor

RRF ve yeniden sıralama

• Sorguyla sadece kelime düzeyinde örtüşen ama gerçekte farklı soruları yanıtlayan dokümanlar üst sıralara çıkabildiği için ayrı bir yeniden sıralama adımı kullanılıyor
• Farklı arama motorlarının sıralı listeleri karşılıklı sıra füzyonu (RRF) ile birleştiriliyor
  • Her doküman için göründüğü her listede weight / (60 + rank) ekleniyor
  • Varsayılan ağırlık 1.0, yumuşatma sabiti 60
  • Birden çok arama motorunda sürekli üst sıralarda görünen dokümanlar, yalnızca tek bir arama motorunda 1. sırada çıkan dokümanları geride bırakabiliyor
• Yinelenen parçalar kaynak birimine göre birleştiriliyor ve dosya başına sonuç sayısı sınırlandırılarak çeşitli bir ilk 20 aday listesi oluşturuluyor
• Küçük bir yeniden sıralama modeli, özgün soruya göre her dokümana 0–10 arasında puan veriyor ve ilk 10 korunuyor
• Sonuçlara çevresel bağlam yeniden ekleniyor
  • Bir wiki bölümü eşleşirse, başlık/ön koşullar/uyarılar parça bölme yüzünden kaybolmasın diye bitişik iki bölüm daha birlikte alınıyor
• Arama sonuçları; birden çok motorun birleşimi, kaynak birimi bazlı tekilleştirme, soru bazlı yeniden sıralama ve çevresel bağlam genişletmesinden geçmiş kanıt paketleri olarak döndürülüyor

MCP ile web arayüzü arasındaki görev paylaşımı

• MCP’de tek bir “soruyu yanıtla” endpoint’i yerine search_slack, search_code, search, who_knows gibi arama temel işlevleri ayrı araçlar olarak sunuluyor
• Araçların hızlı ve düşük maliyetli çağrılabilmesi için mümkün olduğunca LLM bağımlılığı kaldırılıyor
  • Girdi ve çıktı aralıkları dar, yapısal ve kararlı tutuluyor
  • Vektör araması, sözcüksel arama ve ripgrep gibi tekil iş akışlarına hafif puanlama kuralları uygulanarak ham kanıt satırları döndürülüyor
• Claude Code dahil MCP uyumlu ajanlar; hangi aracı, hangi sırayla çağıracağını ve sonuçları nasıl birleştireceğini belirleyen orkestrasyon motoruna dönüşüyor
• Web arayüzünde ise aynı araçlar tek bir tam sorgu iş hattına bağlanıyor
  • Planlayıcı, soruya ve etkin projeye bakıp hangi arama araçlarının çağrılacağını seçiyor
  • Yürütücü, çağrıları paralel işliyor ve bunları puan/güncellik/kaynak ipuçları içeren ortak bir kanıt şemasına dönüştürüyor
  • Sentezleyici, soru ve kanıt paketlerinden; alıntılar, uyarılar ve kaynaklar arası birleştirmeleri içeren cevap üretiyor
• Kullanıcı yalnızca sorusunu sorup cevabını alıyor; ancak içeride planlayıcı → yürütücü → sentezleyici akışı çalışıyor

Proje bazlı arama kapsamı

• Derlem büyüdükçe, tüm organizasyonu her zaman arayan yaklaşımın ilgililiği hızla düştü
  • Derleyici ekibi, altyapı operasyon prosedürlerinin sonuçlarda görünmesini istemiyordu; tersi de aynı şekilde geçerliydi
• Proje, sorguların yürütüldüğü varsayılan çalışma alanı olarak tanıtıldı
  • Belirli Slack kanalları/kod depoları/iç veritabanları/doküman alanları ekip ya da görev bazında gruplanıyor
  • Paylaşılan olay kanalları ya da merkezi platform deposu birden çok projede referans verilebiliyor; veri çoğaltılmıyor
• Onboarding sırasında, ML eğitim altyapısı/Compiler/Data Center Operations gibi işe uygun varsayılan projeler seçiliyor ya da oluşturuluyor
• Varsayılan proje kullanıcı profilinde saklanıyor ve tüm sorgu kapsamı otomatik sınırlandırılıyor; böylece yeni mühendisler ilgili kanal ve depoları önceden öğrenmeden de aramaya başlayabiliyor

Mevcut araçları koruyan bilgi tabanı

• Bilgi tabanının çalışma ilkesi, bilgiyi tek ve katı bir sisteme taşımak yerine zaten üretildiği yerden toplamaktır
• Çok sayıda arama yöntemini birleştirerek kanıtı hızlı bulurken gerçek kurumsal verinin çeşitliliğini de kabul eden ve organizasyon büyüse bile kullanışlı kalan bir yapı kuruldu