Cara Cerebras Membangun Basis Pengetahuan Internal

• Cerebras membangun Cerebras Knowledge, yang mengumpulkan Slack/repositori kode/dokumen/basis data internal langsung dari lokasi asalnya, dan dalam 3 bulan setelah diluncurkan menangani lebih dari 15.000 pertanyaan per hari dari karyawan/otomasi/agen
• Alih-alih memindahkan semua data ke satu alat, sistem ini menghubungkannya ke tabel embedding Postgres dengan skema umum, serta memisahkan lapisan pengumpulan/kueri/autentikasi·otorisasi·audit·analitik agar sumber data baru mudah ditambahkan
• Untuk pencarian Slack, embedding teks mentah saja tidak cukup, sehingga digunakan full-text search/pencarian embedding/inverse document frequency/time decay secara bersamaan, dan ringkasan thread serta kumpulan ujaran individual yang penting di-embedding secara terpisah
• Untuk setiap kueri, LLM terlebih dahulu merencanakan alat pencarian yang akan digunakan, mengumpulkan hasil secara paralel, lalu menggabungkannya dengan RRF dan model reranking; di MCP, fungsi pencarian yang sama diekspos langsung sebagai alat primitif yang kecil dan stabil
• Alih-alih selalu mencari di seluruh organisasi, cakupan pencarian berbasis proyek—yang mengelompokkan channel Slack/repositori/ruang dokumen, dll.—ditetapkan sebagai default agar tiap tim mendapatkan hasil yang lebih relevan

---

Mengumpulkan langsung dari tempat informasi dibuat

• Di tim operasi pusat data/desain chip/perangkat keras/pelatihan/inferensi/platform cloud Cerebras, ratusan orang baru bergabung setiap tahun, sehingga pertanyaan seperti “Di mana X?”, “Siapa ahli Y?”, dan “Apa itu Z?” terus berulang
• Mereka menilai bahwa cara mencatat semua informasi di satu platform tidak berjalan baik dalam pekerjaan nyata
  • Informasi dibuat di alat yang sesuai untuk tiap pekerjaan, seperti usulan perubahan dokumen, thread Slack, referensi kode GitHub, dan metadata status Jira
  • Tiap platform telah dioptimalkan untuk bidang tertentu melalui pengembangan dan analisis produk yang panjang, sehingga mereka memutuskan untuk tidak memaksa orang mengubah cara pemakaiannya
• Pada tahap pengumpulan, sistem terhubung langsung ke tiap platform untuk meminimalkan perubahan perilaku kerja yang sudah ada

Struktur yang berpusat pada tabel embedding umum

• Basis pengetahuan terdiri dari tiga lapisan
  • Platform yang mengumpulkan dan menyimpan data internal
  • Platform untuk mengkueri data yang tersimpan
  • Lapisan yang menerapkan autentikasi/otorisasi/audit/analitik
• Di pusatnya ada satu tabel Postgres yang menyimpan embedding/ringkasan teks asli/metadata dari berbagai sumber
• Thread Slack, repositori kode, sistem dokumen, netlist, dan basis data kustom menggunakan antarmuka baris embedding yang sama
• Tiap sumber data menentukan definisi data, metode koneksi, dan siklus pengumpulan; begitu dicatat ke tabel umum, data itu bisa dicari lewat antarmuka kueri yang sama
• Antarmuka data sengaja dibuat sederhana agar developer Cerebras dapat membuat konektor terpisah

Pencarian hibrida yang dibutuhkan Slack

• Slack adalah sumber data paling penting untuk diskusi engineering terbaru
• Vector search yang hanya menerapkan embedding sederhana pada teks mentah sulit menemukan semua informasi yang relevan
  • Pesan pendek seperti “ya, bagus” dan penjelasan kernel yang rinci disimpan dalam satuan pesan yang sama
  • Pesan pendek sering kali mengungguli pesan yang lebih panjang dan mendetail dalam cosine similarity
  • Makna pesan individual bergantung pada percakapan di sekitarnya
• Setiap thread Slack dicari secara bersamaan dengan empat cara
  • Full-text search menemukan token presisi yang menjadi kabur dalam embedding, seperti string error/nama flag/nama host
  • Pencarian embedding menghubungkan pertanyaan dan jawaban yang dinyatakan dengan kosakata berbeda, seperti “pemulihan berhenti setelah manifest” dan “checkpoint macet pada mount NFS”
  • Inverse document frequency (IDF) menaikkan peringkat pesan pendek yang berisi flag konfigurasi langka dan menurunkan skor frasa respons umum
  • Time decay memprioritaskan thread terbaru dibanding thread lama yang mungkin menjelaskan infrastruktur yang sudah usang, ketika jawabannya sama-sama relevan
• Mereka tidak mempercayai satu skor saja; daftar peringkat dari masing-masing mesin pencari digabungkan pada saat kueri

Pengumpulan real-time berbasis Socket Mode

• Bot Slack dipasang di workspace dan menerima semua event pesan melalui koneksi WebSocket persisten Socket Mode
• Sistem diperbarui secara real-time tanpa perlu memanggil Web API berulang kali, sehingga mengurangi konsumsi rate limit request
• Saat event tiba, sistem langsung merespons, menghapus duplikasi dengan event ID yang stabil, lalu menandainya agar diproses oleh consumer pengumpulan
• Pesan baru tidak disimpan secara mandiri; sistem mengambil ulang seluruh thread tempat pesan itu berada
  • Pesan induk dan semua balasan disimpan sebagai satu baris
  • Ketika balasan ditambahkan ke thread yang sudah ada, pesan induk/balasan saudara/daftar partisipan/waktu aktivitas terakhir semuanya diperbarui
• Setiap channel Slack memiliki sumber data terpisah, sehingga channel yang sering berubah seperti channel respons insiden dapat diberi siklus pengumpulan yang lebih pendek

Distilasi dan penstrukturan thread

• Teks Slack mentah dapat dicari dengan kata kunci segera setelah disimpan melalui indeks full-text GIN Postgres
• Untuk data vector search, LLM mengekstrak item berikut dari seluruh thread
  • Pertanyaan satu baris yang kemungkinan benar-benar dicari engineer
  • Ringkasan pendek
  • Solusi
  • Sistem terkait dan referensi kode
• Item yang diekstrak di-embedding dan disimpan dalam tabel umum; transkrip percakapan asli itu sendiri tidak di-embedding langsung
• Dalam eksperimen, akurasi meningkat besar ketika thread dinormalisasi ke format yang konsisten, dan metadata tambahan juga memberi sinyal yang lebih berguna untuk semantic search

Bursting untuk mempertahankan pesan individual dalam thread panjang

• Ringkasan tingkat thread saja masih menyisakan masalah: pesan penting di dalam percakapan panjang dapat terlewat
• Pesan berurutan dari penulis yang sama digabungkan menjadi kumpulan ujaran berurutan (burst), lalu topik thread ditempelkan di depan sebagai konteks dan di-embedding secara terpisah
• Jawaban dari percakapan sampingan yang tidak masuk ringkasan thread juga dapat dicari secara independen
• Agar ujaran bersinyal rendah tidak masuk basis data, sistem menghitung sinyal berbobot dan hanya menyimpan kumpulan yang melewati ambang
  • Mengandung token langka dengan IDF 4.0 atau lebih di seluruh korpus
  • Panjang ujaran gabungan minimal 200 karakter
  • Satu atau lebih pesan memiliki emoji reaksi sehingga memperoleh bobot sosial
• Kumpulan yang memenuhi syarat disimpan ke tabel embedding umum bersama record tingkat thread

Embedding inkremental untuk repositori kode besar

• Dengan meluasnya alat command-line seperti Claude Code, mereka sempat menganggap grep mungkin cukup untuk kode, tetapi setelah meninjau masukan pelaku industri dan hasil semantic search pada codebase besar dari Cursor, mereka mengadopsi embedding kode
• Beberapa repositori internal berukuran lebih dari 40GB, sehingga biaya untuk terus meng-embedding ulang semuanya menjadi tantangan utama
• Setelah beberapa eksperimen, mereka memilih framework embedding dokumen open source CocoIndex yang terspesialisasi untuk vektorisasi codebase
• Kode dibagi dengan menerapkan batas regex per bahasa dari unit besar ke unit kecil
  • Pertama menggunakan batas tingkat atas seperti class
  • Jika chunk terlalu besar, turun ke method dan batas blok yang lebih kecil
  • Dalam satu file, beberapa embedding dengan granularitas berbeda dapat dibuat, seperti tingkat file/tingkat fungsi
• CocoIndex mempertahankan metadata sinkronisasi di Postgres, sehingga pada setiap commit hanya chunk kode yang berubah yang di-embedding ulang dan diekspor
• Setelah jumlah repositori bertambah, onboarding dialihkan ke file konfigurasi yang dapat diajukan langsung oleh tim, serta mendukung allowlist/blocklist berdasarkan path file

Menghubungkan sumber data kustom

• Beberapa tim ingin menggunakan antarmuka pencarian yang sama tanpa memindahkan informasi dari basis data yang sudah ada ke Slack atau sistem dokumen
• Sumber kustom diperlakukan sebagai skrip plugin
  • Tim mengajukan pull request berisi modul Python kecil yang membaca sistem yang sudah ada dan mengekspor baris dalam bentuk tabel embedding umum
  • Konfigurasi sumber data yang sesuai juga ditambahkan bersamanya
• Selama dicatat ke basis data bersama dengan skema umum, data itu akan dicari bersama Slack/kode/dokumen, dan bagian sistem lainnya tidak memerlukan penanganan khusus

Perencanaan kueri dan eksekusi alat paralel

• Untuk setiap pertanyaan, LLM terlebih dahulu menjalankan tahap perencanaan singkat untuk menentukan alat dan sumber data yang akan digunakan
• Alat utamanya adalah sebagai berikut
  • subsystem_index: ringkasan LLM per file
  • search: vector search yang mengintegrasikan indeks Slack/wiki/kode/lainnya dan melakukan penggabungan serta reranking secara internal
  • search_slack: pencarian langsung Slack
  • search_code: ripgrep terhadap repositori sumber
  • recent_prs: pull request terbaru yang terkait dengan pertanyaan
  • who_knows: mencari orang yang benar-benar menunjukkan keahlian pada topik tertentu
• Planner menggunakan daftar proyek/sumber data per proyek/deskripsi ringkas tentang pertanyaan yang cocok dijawab oleh tiap sumber
• Executor memanggil alat yang dipilih secara paralel, menormalkan hasil ke format bukti umum, lalu meneruskannya ke LLM sintesis akhir

RRF dan reranking

• Karena dokumen yang hanya berbagi kosakata dengan kueri tetapi sebenarnya menjawab pertanyaan lain bisa muncul di posisi atas, mereka menambahkan tahap reranking terpisah
• Daftar peringkat dari mesin pencari yang berbeda digabungkan dengan Reciprocal Rank Fusion (RRF)
  • Untuk setiap daftar tempat dokumen muncul, ditambahkan weight / (60 + rank)
  • Bobot default adalah 1.0, konstanta smoothing adalah 60
  • Dokumen yang muncul secara merata di peringkat atas pada beberapa mesin pencari dapat mengungguli dokumen yang hanya menempati posisi pertama pada satu mesin pencari
• Chunk duplikat digabungkan berdasarkan unit asal dan jumlah hasil per file dibatasi untuk membuat 20 kandidat teratas yang beragam
• Model reranking kecil memberi skor 0–10 pada tiap dokumen berdasarkan pertanyaan asli dan menyisakan 10 teratas
• Konteks sekitar ditambahkan kembali ke hasil akhir
  • Jika bagian wiki cocok, dua bagian yang berdekatan ikut diambil agar judul/prasyarat/peringatan tidak hilang akibat pemotongan chunk
• Hasil pencarian dikembalikan sebagai kumpulan bukti yang telah melalui penggabungan beberapa mesin pencari/dedup berdasarkan unit asal/reranking berbasis pertanyaan/perluasan konteks sekitar

Pembagian peran MCP dan UI web

• Di MCP, alih-alih satu endpoint “jawab pertanyaan”, fungsi dasar pencarian seperti search_slack, search_code, search, who_knows diekspos sebagai alat masing-masing
• Dependensi pada LLM dihilangkan sebisa mungkin agar alat dapat dipanggil cepat dan murah
  • Ruang lingkup input dan output dijaga sempit, terstruktur, dan stabil
  • Pipeline tunggal seperti vector search/lexical search/ripgrep diberi aturan skor ringan untuk mengembalikan baris bukti mentah
• Agen yang kompatibel dengan MCP, termasuk Claude Code, menjadi mesin orkestrasi yang menentukan alat yang dipanggil/urutan/kombinasi hasil
• Di UI web, alat yang sama dihubungkan menjadi satu pipeline kueri lengkap
  • Planner melihat pertanyaan dan proyek aktif untuk memilih alat pencarian yang akan dipanggil
  • Executor memproses panggilan secara paralel dan mengubahnya ke skema bukti umum yang mencakup skor/kebaruan/petunjuk sumber
  • Synthesizer menghasilkan jawaban dari pertanyaan dan kumpulan bukti, termasuk kutipan/peringatan/integrasi lintas sumber
• Pengguna cukup bertanya dan menerima jawaban, tetapi di dalamnya alur planner → executor → synthesizer dijalankan

Cakupan pencarian berbasis proyek

• Ketika korpus membesar, relevansi dari cara yang selalu mencari di seluruh organisasi turun drastis
  • Tim compiler tidak ingin prosedur operasi infrastruktur muncul di hasil pencarian, dan sebaliknya juga sama
• Proyek diperkenalkan sebagai workspace default tempat kueri dijalankan
  • Channel Slack/repositori kode/basis data internal/ruang dokumen tertentu dikelompokkan berdasarkan tim atau tugas
  • Satu channel insiden bersama atau repositori platform pusat dapat dirujuk oleh beberapa proyek tanpa mereplikasi data
• Dalam proses onboarding, pengguna memilih atau membuat proyek default yang sesuai dengan pekerjaan, seperti infrastruktur pelatihan ML/Compiler/Data Center Operations
• Proyek default disimpan di profil pengguna dan cakupan semua kueri dibatasi otomatis, sehingga engineer baru dapat mulai mencari tanpa perlu terlebih dahulu mengenali channel dan repositori yang relevan

Basis pengetahuan yang mempertahankan alat yang sudah ada

• Prinsip kerja basis pengetahuan ini adalah mengumpulkan informasi dari tempat informasi itu sudah dibuat, bukan memindahkannya ke satu sistem yang kaku
• Dengan menggabungkan berbagai metode pencarian, sistem ini menemukan bukti dengan cepat sekaligus mengakomodasi keragaman data perusahaan nyata, dan membangun struktur yang tetap berguna saat organisasi tumbuh