Memilih Model Embedding: Benchmark Praktis

Setiap proyek retrieval-augmented generation cepat atau lambat sampai pada persimpangan yang sama: model embedding mana yang sebenarnya layak masuk ke produksi. Papan peringkat MTEB membuat ini terlihat seperti masalah ranking sederhana, ambil saja model yang berada di puncak lalu lanjutkan. Pada praktiknya ini lebih mirip keputusan sistem daripada sekadar melihat papan peringkat, karena jumlah dimensi, harga per token, latensi, dan seberapa baik model menangani bahasa serta domain spesifik Anda semuanya menarik ke arah yang berbeda.

Tulisan ini membahas trade-off yang benar-benar saya pertimbangkan saat memilih model embedding untuk proyek klien, mengapa skor benchmark agregat hanya titik awal dan bukan vonis akhir, bagaimana model multibahasa berperilaku berbeda pada teks berbahasa Indonesia dibandingkan skor bahasa Inggrisnya, dan sebuah kerangka evaluasi recall at k kecil yang bisa Anda jalankan pada pasangan kueri dan dokumen berlabel milik Anda sendiri sebelum berkomitmen pada satu model.

Mengapa angka papan peringkat bukan segalanya

Massive Text Embedding Benchmark menggabungkan skor dari puluhan dataset dan delapan kategori tugas, termasuk klasifikasi, clustering, dan retrieval. Skor MTEB keseluruhan sebuah model adalah rata-rata dari tugas-tugas yang mungkin tidak ada hubungannya dengan kasus penggunaan Anda. Model yang unggul dalam kemiripan kalimat atau clustering tetap bisa kurang baik pada jenis retrieval asimetris dari kueri ke dokumen panjang yang justru dibutuhkan RAG.

• Ketidakcocokan tugas: aplikasi Anda membutuhkan kualitas retrieval, tetapi sebagian skor agregat berasal dari tugas klasifikasi dan clustering yang tidak menyerupai kueri pencarian yang mencocokkan sebuah paragraf.
• Ketidakcocokan domain: model yang dilatih pada Wikipedia dan data crawl web tidak otomatis dapat diterapkan pada baris item faktur, klausul hukum, atau nama field ERP.
• Ketidakcocokan bahasa: skor retrieval bahasa Inggris hampir tidak memberi tahu apa pun tentang bagaimana model yang sama merangking dokumen ketika kueri dan korpusnya berbahasa Indonesia.

Ukuran dimensi, biaya, dan apa yang sebenarnya Anda korbankan

Setiap model embedding mempublikasikan dimensi vektor asli, dan sebagian besar model modern memungkinkan Anda memotong vektor tersebut menjadi ukuran lebih kecil tanpa menghitung ulang, teknik yang umum disebut representasi Matryoshka. Vektor yang lebih kecil berarti penyimpanan lebih murah, pencarian kemiripan lebih cepat, dan beban memori lebih rendah pada indeks vektor Anda, tetapi bisa diam-diam mengorbankan recall pada kueri yang lebih sulit. Tabel di bawah adalah perbandingan kasar beberapa model yang umum dipakai untuk RAG pada tahun 2026.

Aturan praktis yang berguna: dokumentasi resmi OpenAI mencatat bahwa model embedding besar yang dipotong menjadi ukuran jauh lebih kecil tetap bisa mengungguli model lama yang tidak dipotong pada ukuran penuh. Artinya pertanyaan yang jujur jarang sekali soal model mana yang punya vektor terbesar, melainkan model mana yang mempertahankan sinyal paling berguna pada ukuran dimensi yang benar-benar mampu diindeks dan dikueri infrastruktur Anda pada skala produksi.

Performa multibahasa dan kesenjangan bahasa Indonesia

Jika sebagian korpus Anda berbahasa Indonesia, peringkat papan peringkat berbahasa Inggris sebaiknya dianggap sebagai derau, bukan sinyal. Massive Multilingual Text Embedding Benchmark memperluas cakupan ke ratusan bahasa justru karena evaluasi khusus bahasa Inggris menyembunyikan kesenjangan performa yang besar. Temuan yang dipublikasikan benchmark ini menjadi pemeriksaan akal sehat yang baik terhadap asumsi bahwa model yang lebih besar selalu menang: model multibahasa publik terkuat dalam evaluasi tersebut hanya memiliki beberapa ratus juta parameter, jauh di bawah banyak model embedding tujuan umum.

• Korpus campuran bahasa, di mana kueri berbahasa Indonesia perlu mengambil dokumen teknis berbahasa Inggris atau sebaliknya, memberi tekanan berbeda pada model dibandingkan retrieval satu bahasa, dan tidak semua model multibahasa menanganinya dengan baik.
• Tokenisasi lebih berpengaruh dari yang diperkirakan orang. Imbuhan dan reduplikasi bahasa Indonesia bisa terpecah buruk pada tokenizer yang sebagian besar dilatih dengan korpus bahasa Inggris dan Mandarin, yang diam-diam merugikan retrieval pada kueri pendek.
• Model multibahasa yang disetel dengan instruksi, di mana Anda menambahkan deskripsi tugas singkat sebelum kueri di-embed, sering kali menutup sebagian besar kesenjangan pada retrieval bahasa Indonesia tanpa perlu model yang lebih besar.

Membenchmark pada data Anda sendiri, bukan mempercayai papan peringkat

Satu-satunya benchmark yang secara andal memprediksi perilaku produksi adalah benchmark yang dibangun dari kueri dan dokumen Anda sendiri. Anda tidak butuh ribuan pasangan berlabel untuk mendapatkan sinyal yang berguna secara arah, tiga puluh hingga lima puluh pasangan kueri dan dokumen relevan yang realistis, diambil dari tiket dukungan sungguhan, log pencarian sungguhan, atau beberapa jam pelabelan manual, sudah cukup untuk memisahkan model yang benar-benar lebih baik dari model yang sekadar lebih populer. Skrip di bawah menghitung recall at k, yaitu proporsi kueri di mana dokumen yang benar muncul dalam k hasil retrieval teratas, untuk model embedding apa pun yang menyediakan pemanggilan embedding secara batch.

// Minimal recall@k harness against your own labeled pairs
import { OpenAI } from "openai"

interface EvalPair {
  query: string
  relevantDocId: string
}

const openai = new OpenAI()

async function embed(texts: string[], model: string) {
  const res = await openai.embeddings.create({ model, input: texts })
  return res.data.map((d) => d.embedding)
}

function cosineSim(a: number[], b: number[]) {
  let dot = 0, magA = 0, magB = 0
  for (let i = 0; i < a.length; i++) {
    dot += a[i] * b[i]
    magA += a[i] * a[i]
    magB += b[i] * b[i]
  }
  return dot / (Math.sqrt(magA) * Math.sqrt(magB))
}

async function recallAtK(
  pairs: EvalPair[],
  corpus: { id: string; text: string }[],
  model: string,
  k = 5
) {
  const corpusVecs = await embed(corpus.map((c) => c.text), model)
  const queryVecs = await embed(pairs.map((p) => p.query), model)

  let hits = 0
  pairs.forEach((pair, i) => {
    const scored = corpus.map((doc, j) => ({
      id: doc.id,
      score: cosineSim(queryVecs[i], corpusVecs[j]),
    }))
    scored.sort((a, b) => b.score - a.score)
    const topK = scored.slice(0, k).map((s) => s.id)
    if (topK.includes(pair.relevantDocId)) hits++
  })

  return hits / pairs.length
}

Jalankan skrip yang sama terhadap setiap model kandidat dengan pasangan kueri dan dokumen yang sama, dan Anda mendapatkan perbandingan setara yang memperhitungkan strategi chunking Anda yang sebenarnya, panjang dokumen Anda yang sebenarnya, dan kosakata Anda yang sebenarnya, semua hal yang tidak bisa dilihat oleh papan peringkat publik. Biasanya prosesnya memakan waktu kurang dari satu jam untuk dijalankan terhadap tiga atau empat model kandidat setelah pasangan berlabel tersedia.

Daftar periksa keputusan sebelum berkomitmen

Setelah Anda memiliki angka recall dari data Anda sendiri, beberapa batasan praktis biasanya mempersempit pilihan menjadi satu atau dua opsi realistis.

1. Pastikan panjang token input maksimum model mencakup ukuran chunk terbesar Anda, termasuk metadata apa pun yang Anda tambahkan sebelum chunk tersebut di-embed.
2. Tentukan apakah API terkelola atau model self-hosted sesuai dengan kebutuhan latensi dan residensi data Anda, karena mengirim dokumen pelanggan ke API pihak ketiga adalah batasan nyata bagi sebagian klien.
3. Perkirakan total biaya embedding pada volume dokumen yang diharapkan, bukan sekadar harga per token, karena melakukan re-embedding seluruh korpus setelah perubahan strategi chunking cepat membengkak pada skala besar.
4. Tetapkan rencana re-embedding sebelum peluncuran. Membandingkan dot product mentah antara vektor yang dihasilkan oleh dua model embedding berbeda tidak bermakna, sehingga berganti model di kemudian hari berarti mengindeks ulang semuanya, bukan hanya dokumen baru.

Apa yang sebenarnya saya rekomendasikan

Untuk proyek RAG tujuan umum berbahasa Inggris murni dengan anggaran ketat, model terkelola kecil dengan dimensi terpotong adalah pilihan default yang masuk akal. Untuk apa pun yang menyentuh konten berbahasa Indonesia, model multibahasa self-hosted yang dievaluasi khusus pada pasangan kueri dan dokumen berbahasa Indonesia secara konsisten mengungguli model terkelola yang disetel untuk bahasa Inggris dalam pengujian saya sendiri, bahkan ketika model terkelola tersebut menang di papan peringkat umum. Apa pun yang Anda pilih, perlakukan keputusan itu sebagai bisa dibalik hanya jika Anda telah menganggarkan waktu untuk melakukan re-embedding seluruh korpus, karena embedding dari model berbeda tidak pernah bisa dibandingkan satu sama lain.