Topik wawancara representatif

Wawancara system design: Bagaimana Anda merancang layanan pencarian vektor multi-tenant?

Desain sistemSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Anda memerlukan layanan yang menyimpan embedding untuk 100 juta dokumen di banyak tenant. Kueri harus mengembalikan 20 dokumen relevan teratas dalam waktu 150 ms pada p95, menerapkan filter tenant dan ACL, membuat pembaruan dapat dicari dalam waktu satu menit, serta mengekspos metrik recall, biaya, dan kesegaran (freshness). Rancang layanan tersebut dan jelaskan pengindeksan, sharding, pemfilteran, pembaruan, dan evaluasi.

Perintah dan cakupan

Ini adalah masalah perancangan sistem temu balik (retrieval), bukan permintaan untuk menyebutkan nama basis data vektor. Tujuannya adalah pencarian semantik atas embedding dengan isolasi tenant yang ketat, filter metadata dan izin, latensi berbatas, serta kontrak kesegaran dan relevansi yang dapat diukur. Asumsikan embedding dihasilkan oleh model upstream, dokumen dapat diganti atau dihapus, dan layanan harus mendukung pengisian ulang massal (batch backfill) maupun pembaruan berkelanjutan.

Apa yang diuji oleh pewawancara

  • Apakah Anda memisahkan penyerapan (ingestion), embedding, pembuatan indeks, penanganan kueri (query serving), dan evaluasi.
  • Apakah Anda menjelaskan mengapa pencarian eksak terlalu mahal dan memilih strategi approximate nearest-neighbor (ANN) secara matang.
  • Apakah filter diterapkan tanpa merusak recall atau isolasi tenant secara diam-diam.
  • Apakah operasi pembaruan, penghapusan, perubahan model, dan pembangunan ulang indeks memiliki semantik visibilitas yang eksplisit.
  • Apakah Anda mendefinisikan metrik relevansi, recall, latensi, biaya, dan kesegaran alih-alih sekadar mengklaim bahwa "kemiripan" sudah benar.

Pertanyaan untuk diklarifikasi terlebih dahulu

  • Berapa dimensi vektor, fungsi jarak, jumlah dokumen per tenant, dan perkiraan laju kueri?
  • Apakah filter tenant dan ACL merupakan batasan mutlak (hard constraints), atau hasil dapat disaring setelah temu balik (retrieval)?
  • Apakah kesegaran satu menit diperlukan untuk setiap penulisan, atau hanya untuk sebagian subset koleksi yang aktif (hot)?
  • Apakah kita memerlukan pencarian hibrida kata kunci plus vektor, pemeringkatan ulang (reranking), atau hanya temu balik tetangga terdekat?
  • Bisakah model embedding berubah, dan apakah vektor lama harus tetap dapat dikueri selama migrasi?

Kerangka jawaban 30 detik

"Saya akan membagi sistem menjadi log penyerapan, worker embedding, indeks vektor berversi, dan lapisan kueri tanpa status (stateless). Setiap rekaman membawa tenant, ACL, versi dokumen, versi model, dan status tombstone. Perutean kueri pertama-tama memilih shard atau namespace tenant, kemudian melakukan pencarian ANN berfilter dan secara opsional melakukan pemeringkatan ulang terhadap sejumlah kecil kandidat. Indeks delta yang dapat diubah (mutable) menangani penulisan terkini sementara segmen yang tidak dapat diubah (immutable) dibangun ulang di latar belakang; operasi baca menggabungkan keduanya dan menyembunyikan versi usang. Saya akan mengukur recall terhadap gold set yang eksak atau terkurasi, latensi p95, rasio luput filter (filter miss rate), jeda kesegaran, dan biaya per kueri."

Penyelaman mendalam langkah demi langkah

1. Tentukan kontrak data dan visibilitas

Simpan document_id, tenant_id, atribut ACL, versi model embedding, versi konten, vektor, dan stempel waktu pembaruan. Penghapusan adalah tombstone dengan versi, bukan asumsi langsung bahwa setiap replika telah menghapus vektor tersebut. Kueri diotorisasi sebelum temu balik; predikat tenant dan ACL adalah batasan wajib, sedangkan pemeringkatan relevansi hanya diterapkan pada kandidat yang telah diotorisasi.

2. Pilih indeks ANN dan partisi

Pencarian brute-force memerlukan sekitar O(N × D) operasi jarak untuk N vektor dengan dimensi D. Pada 100 juta vektor, hal ini tidak cocok untuk target 150 ms, jadi gunakan indeks ANN seperti HNSW atau pendekatan inverted-file. HNSW mengutamakan recall tinggi dan pembacaan cepat dengan overhead memori; indeks terklaster atau terkuantisasi mengurangi memori dan biaya tetapi menambah risiko penyesuaian (tuning) dan penurunan recall. Mulailah dengan namespace atau shard yang sadar tenant, kemudian pisahkan tenant yang padat dan replikasi partisi yang sering dibaca. Jangan mengklaim angka Big-O atau recall yang universal; lakukan tolok ukur (benchmark) pada pustaka dan dimensi yang dipilih.

3. Jadikan pemfilteran bagian dari kebenaran temu balik

Pasca-pemfilteran (post-filter) dapat mengembalikan kurang dari 20 hasil jika tetangga terdekat milik tenant lain atau gagal dalam predikat ACL. Pra-pemfilteran (pre-filter) dapat memperkecil ruang kandidat tetapi dapat membuat filter yang jarang (sparse) menjadi mahal. Desain praktis menjaga metadata yang dapat difilter tetap terindeks di samping jalur vektor, memperkirakan selektivitas, dan memilih kumpulan kandidat ANN yang lebih besar atau segmen terfilter khusus saat dibutuhkan. Pinecone mendokumentasikan predikat metadata dan memperingatkan bahwa pemfilteran adalah bagian dari kontrak pencarian; jawaban wawancara harus menyatakan apa yang terjadi jika ada kurang dari 20 kecocokan yang terotorisasi.

4. Pisahkan penulisan baru dari segmen yang dipadatkan

Tambahkan penulisan yang diterima ke log yang tahan lama (durable) dan indeks delta kecil yang dapat diubah. Kueri kedua segmen dasar yang immutable dan delta, kemudian gabungkan berdasarkan versi dokumen dan hapus ID yang telah di-tombstone. Pemadatan (compaction) latar belakang membangun segmen baru, memverifikasi hitungan dan sampel recall, serta menukar manifes secara atomik. SLA satu menit diukur dari penulisan yang diakui hingga visibilitas kueri, bukan dari awal pekerjaan embedding. Jika embedding atau pengindeksan tertunda, ekspos jeda tersebut dan pertahankan versi sebelumnya tetap terlihat alih-alih berpura-pura bahwa penulisan berhasil.

5. Tangani migrasi model dan skema

Perubahan model embedding membuat vektor lama dan baru tidak dapat dibandingkan kecuali jika sistem mendukung indeks ganda atau rencana proyeksi. Tuliskan versi model ke dalam setiap rekaman, isi ulang indeks baru, lakukan kueri bayangan (shadow queries) terhadap keduanya, dan bandingkan recall serta latensi sebelum beralih. Pertahankan indeks lama sampai persyaratan rollback dan retensi berakhir. Perubahan skema metadata dan ACL memerlukan disiplin peluncuran berversi yang sama; kecocokan vektor tidak boleh mengabaikan bidang izin yang baru ditambahkan.

6. Rancang jalur kueri dan kebijakan kelebihan beban

Lapisan kueri mengautentikasi tenant, menormalisasi kueri, memilih versi model, dan melakukan fan-out hanya ke shard yang relevan. Lapisan ini menerapkan batas waktu (deadline), jumlah kandidat terbatas, dan pembatalan. Jika shard mengalami waktu habis (timeout), kembalikan hasil parsial hanya jika API menandai kelengkapan; jika tidak, fail closed untuk pencarian yang sensitif terhadap keamanan. Cache embedding dan kueri publik yang stabil, tetapi jangan pernah membagikan entri cache lintas cakupan otorisasi. Kontrol penerimaan (admission control) melindungi memori indeks dan kapasitas pemeringkatan ulang saat terjadi lonjakan beban.

7. Ukur relevansi, kesegaran, dan biaya

Buat kumpulan kueri berlabel dengan dokumen yang relevan dan terlarang. Bandingkan hasil ANN dengan baseline pencarian eksak pada partisi sampel, dan laporkan recall@20, presisi atau nDCG, kebenaran filter, serta uji kebocoran otorisasi. Lacak latensi p50/p95/p99, jumlah kandidat, waktu pembuatan indeks, jeda tulis-ke-terlihat, backlog tombstone, memori per vektor, dan biaya per seribu kueri. Metrik offline menangkap regresi pemeringkatan; metrik klik online memerlukan pengaman (guardrails) karena bias posisi dapat membuat hasil yang buruk terlihat populer.

Pertukaran (Trade-offs) dan batasan

HNSW versus indeks terklaster atau terkuantisasi

HNSW adalah pilihan awal yang kuat untuk beban kerja baca tinggi ketika memori tersedia. IVF atau kuantisasi produk dapat mengurangi memori dan meningkatkan efisiensi pemindaian pada skala besar, tetapi memerlukan pelatihan, penyesuaian, dan validasi recall. Pilihlah berdasarkan laju pembaruan, dimensi, ketimpangan tenant, dan anggaran perangkat keras; jangan memilih hanya berdasarkan nama produk.

Penyimpanan vektor bawaan versus basis data yang ada

Basis data serbaguna dengan indeks vektor menarik jika koleksinya moderat dan join, transaksi, serta data ACL harus tetap bersama. Layanan khusus dibenarkan jika pencarian vektor mendominasi kapasitas, memerlukan indeks ANN khusus, atau membutuhkan penskalaan independen. Simpan rekaman dokumen dan izin yang menjadi sumber kebenaran (source-of-truth) di luar indeks jika penyimpanan vektor tidak dapat memberikan jaminan transaksional yang diperlukan.

Satu indeks per tenant versus partisi bersama

Indeks per tenant menyederhanakan isolasi dan kontrol noisy-neighbor tetapi melipatgandakan overhead. Indeks bersama memanfaatkan perangkat keras dengan lebih baik, namun membutuhkan pemfilteran metadata yang ketat dan penjadwalan yang adil. Gunakan namespace atau kunci partisi untuk tenant biasa dan alihkan tenant yang sangat besar atau yang diatur secara ketat ke kapasitas terisolasi.

Contoh jawaban berkualitas tinggi

"Saya akan memulai dengan log penulisan yang tahan lama dan membuat versi untuk setiap dokumen, ACL, dan model embedding. Lapisan kueri mengotorisasi tenant, melakukan fan-out ke shard yang relevan, menjalankan pencarian ANN berfilter, dan menggabungkan indeks delta baru dengan segmen immutable. HNSW adalah baseline untuk beban baca tinggi, tetapi saya akan membandingkannya dengan indeks terklaster atau terkuantisasi menggunakan recall@20 dan latensi p95. Pembangunan ulang mempublikasikan manifes secara atomik, perubahan model menggunakan kueri bayangan, dan penghapusan diperlakukan sebagai tombstone berversi. Layanan ini melaporkan kebenaran filter, jeda tulis-ke-terlihat, uji kebocoran otorisasi, memori per vektor, dan biaya kueri; relevansi adalah kontrak yang terukur."

Kesalahan umum

  • Memperlakukan pilihan pustaka ANN sebagai keseluruhan arsitektur sambil mengabaikan penyerapan, penghapusan, dan pembangunan ulang.
  • Menerapkan filter ACL setelah temu balik dan secara diam-diam mengembalikan dokumen yang lebih sedikit atau tidak terotorisasi.
  • Mengklaim recall atau latensi tetap tanpa menyebutkan dimensi, pengaturan indeks, perangkat keras, dan beban kerja.
  • Mengganti model embedding di tempat sehingga vektor lama dan baru menjadi tidak dapat dibandingkan.
  • Hanya mengukur klik dan tidak pernah mempertahankan baseline relevansi yang eksak atau berlabel.

Pertanyaan lanjutan dan jawaban

Bagaimana jika filter ACL hanya menyisakan tiga kecocokan?

Kembalikan tiga kecocokan dengan sinyal total_or_completeness yang eksplisit, atau kembalikan respons kosong/tidak mencukupi sesuai dengan kontrak API. Jangan pernah mengisi slot yang tersisa dengan hasil yang tidak terotorisasi atau tidak terfilter. Tingkatkan kumpulan kandidat hanya di dalam jalur pencarian yang terotorisasi.

Bagaimana cara membangun ulang indeks tanpa kehilangan data penulisan?

Putar ulang (replay) log tahan lama ke dalam segmen baru, catat batas atas (high-water mark), kejar ketertinggalan penulisan setelah tanda tersebut, validasi hitungan dan sampel recall, lalu publikasikan manifes secara atomik. Jaga agar jalur delta tetap aktif hingga pertukaran selesai; lakukan rollback dengan memulihkan manifes sebelumnya.

Kapan Anda dapat menghapus vektor model lama?

Hanya setelah evaluasi bayangan berhasil, model baru telah melayani lalu lintas, jendela rollback dan retensi ditutup, dan setiap jalur kueri menolak versi model lama. Menghapus hanya berdasarkan waktu tidak aman jika pekerjaan yang tertunda atau konsumen pemutaran ulang masih mereferensikannya.

Sumber publik

Pertanyaan terkait

Alat wawancara terkait

Gunakan Jawab untuk jawaban desain sistem

Perjelas persyaratan terlebih dahulu, lalu lanjutkan dengan skala, arsitektur, pilihan komponen, dan trade-off.

Lihat alat