Mengganti model embedding dapat terlihat seperti upgrade dependency biasa: ganti identifier model, deploy service, lalu terus query vector index yang ada. Pendekatan tersebut dapat merusak retrieval secara diam-diam.

Embedding memiliki makna relatif terhadap ruang representasi yang dihasilkan modelnya. Jika stored document vector dibuat oleh satu model sementara query vector baru dibuat oleh model lain, koordinat keduanya umumnya tidak memiliki makna bersama. Dimensi yang sama tidak cukup untuk membuat vektor kompatibel.

Pola migrasi yang aman adalah memberi versi pada ruang embedding, membangun index baru di samping index lama, mengevaluasi keduanya pada query yang sama, lalu mengalihkan traffic hanya setelah sistem baru memenuhi target kualitas dan operasional.

Perlakukan model embedding sebagai bagian dari schema index

Vector index tidak berisi makna yang independen dari model. Index menyimpan koordinat numerik yang dihasilkan proses embedding tertentu.

documents -> model A -> vectors A -> index A
queries   -> model A -> vectors A -> search index A

Kedua sisi menggunakan fungsi representasi yang sama. Jika hanya query path diganti:

documents -> model A -> vectors A -> index A
queries   -> model B -> vectors B -> search index A

meskipun model A dan B sama-sama menghasilkan vektor 768 dimensi, coordinate 42 pada satu ruang tidak harus sebanding dengan coordinate 42 pada ruang lain. Model dapat merotasi, menskalakan, atau mengorganisasi representasi secara berbeda.

Invariant praktisnya adalah:

query embedding version == indexed document embedding version

kecuali kedua model secara eksplisit dirancang dan divalidasi menghasilkan representasi kompatibel. Jangan menyimpulkan kompatibilitas dari vector dimension, architecture family, provider, atau kemiripan nama model.

Lihat failure melalui contoh kecil

Anggap model A menghasilkan ruang dua dimensi:

                 x      y
query A        0.9    0.1
doc cats       0.8    0.2
doc billing   -0.7    0.1
doc travel     0.0    0.9

Query dekat dengan doc cats. Jika model B merepresentasikan query yang sama sebagai:

query B        0.1    0.9

mencari vector model A memakai query model B dapat membuat doc travel terlihat paling dekat. Tidak ada yang salah dengan kedua model; kesalahannya adalah membandingkan koordinat dari ruang berbeda seolah-olah axis system-nya sama.

Jika preprocessing berubah bersama model—misalnya truncation, prefix, normalization, chunk text, atau field yang di-embed—preprocessing tersebut juga menjadi bagian dari versi representasi.

Beri setiap representasi versi eksplisit

Definisikan kontrak ruang embedding, misalnya:

embedding_version: support-v3
model:            <exact model identifier>
preprocessing:    <versioned pipeline>
dimensions:       <output dimension>
metric:           cosine
chunking:         <versioned chunk policy>

embedding_version sebaiknya merujuk pada kontrak representasi lengkap, bukan label ambigu seperti latest. Simpan versi pada indexed record atau jadikan properti immutable index, dan sertakan pada log retrieval.

Hindari memakai ulang nama index yang sama untuk representasi berbeda. Nama seperti support-chunks-emb-v2 dan support-chunks-emb-v3 lebih mudah diaudit, sementara alias support-chunks-active dapat menunjuk ke physical index yang sedang aktif.

Bangun index baru di samping index lama

Migrasi umum yang paling aman adalah rebuild side-by-side:

                     -> model A -> index A -> current production
source documents ----|
                     -> model B -> index B -> candidate system

Re-embed source corpus dengan pipeline representasi baru dan tulis vektor ke index terpisah. Pertahankan index lama selama proses. Production query tetap memakai representasi yang diketahui, partial backfill tidak mencampur ruang vektor, evaluasi dapat membandingkan sistem lengkap, dan rollback tetap tersedia.

Pisahkan source data dari vector storage

Vector index sebaiknya merupakan derived state, bukan satu-satunya salinan konten. Simpan stable document/chunk identifier dan source data yang cukup untuk meregenerasi embedding.

for each source chunk:
    text = preprocess(chunk, version="v3")
    vector = embed(text, model="model-b")
    write(index="support-chunks-emb-v3", id=chunk.id, vector=vector)

Dalam production, tambahkan batching, retry handling, rate limit, idempotent write, progress checkpoint, dan validasi failed record sesuai kebutuhan.

Tangani write selama rebuild panjang

Jika corpus berubah selama backfill, snapshot awal dapat menjadi stale sebelum index baru siap. Pilihan umum adalah rebuild dari snapshot konsisten lalu replay perubahan, dual-write content baru/updated ke kedua pipeline selama migrasi, atau menjalankan final incremental synchronization sebelum cutover.

Tetapkan completion condition yang jelas; “sebagian besar vector sudah ditulis” tidak cukup jika record yang hilang memuat konten penting.

Evaluasi retrieval sebelum generation

Pada RAG, membandingkan final answer saja dapat menyembunyikan retrieval regression karena generation menambahkan sumber variasi lain. Bandingkan retrieval system langsung pada evaluation set tetap:

same query set
    |-> model A + index A -> ranked results A
    |-> model B + index B -> ranked results B

Setiap query evaluasi perlu memiliki definisi evidence yang berguna. Ukuran dapat berupa recall pada cutoff tertentu, precision, reciprocal rank, atau metric lain yang sesuai kebutuhan produk. Jika generator membutuhkan setidaknya satu supporting passage pada lima hasil pertama, ukur apakah evidence tersebut muncul di sana.

Sertakan ordinary case dan slice penting: query pendek/panjang, product identifier, paraphrase, ambiguous query, rare topic, serta bahasa/domain yang benar-benar dilayani. Aggregate score dapat menyembunyikan regression berat pada slice kecil namun penting.

Setelah retrieval quality memadai, jalankan evaluasi RAG end-to-end karena ranking baru dapat mengubah passage yang masuk ke context, urutan, dan jumlah evidence yang muat.

Bandingkan kualitas, latency, dan cost bersama-sama

Model embedding baru bukan otomatis upgrade hanya karena lebih baik pada satu benchmark.

Re-embedding corpus besar membutuhkan inference dan index-write capacity. Ukur query embedding latency terpisah dari vector search latency. Perubahan vector dimension mengubah raw vector payload, tetapi tidak berarti total index berubah dengan rasio yang sama karena metadata dan search structure juga memakai storage.

Ranking yang lebih baik kadang memungkinkan context lebih kecil, tetapi itu keputusan empiris, bukan jaminan model embedding. Evaluasi answer quality pada context size yang memang akan digunakan.

Shadow traffic sebelum cutover

Offline evaluation set tidak selalu mencakup pola production query. Shadow evaluation dapat memperlihatkan perbedaan pada real traffic tanpa mengubah hasil yang diterima user:

production: query -> model A -> index A -> returned results
shadow:     query -> model B -> index B -> logged results only

Bandingkan retrieval metric jika label tersedia. Jika tidak, periksa result overlap, score distribution, latency, empty-result rate, dan slice query. Overlap rendah tidak otomatis buruk; sistem baru memang diharapkan mengubah sebagian ranking.

Query sensitif tetap memerlukan privacy, retention, dan access control yang sama karena shadowing menambah jalur processing dan logging.

Cutover secara atomik dan sederhanakan rollback

Setelah index baru lengkap dan candidate system lolos evaluasi, ubah query embedding dan pemilihan index sebagai satu logical change.

Cutover yang buruk:

1. deploy model B for queries
2. later point search to index B

Di antara kedua langkah, query model B akan mengenai vector model A.

Lebih aman:

retrieval version v2 -> model A + index A
retrieval version v3 -> model B + index B

active version: v2 -> v3

Aplikasi memilih complete retrieval version yang mengikat query model ke index pasangannya. Pertahankan versi sebelumnya selama rollback window jika kondisi operasional memungkinkan. Rollback harus mengembalikan query embedding path dan index lama bersama-sama.

Hindari kesalahan migrasi umum

Hanya memeriksa vector dimension. Dimensi sama membuat vektor kompatibel secara struktur bagi software, bukan secara semantik.

Memperbarui dokumen secara lazy dalam satu shared index. Campuran vector dari model A dan B membuat satu query dibandingkan terhadap ruang yang berbeda. Gunakan index terpisah atau desain yang menjamin search tetap dalam satu representation version.

Mengubah banyak komponen tanpa tracking. Model baru, chunking baru, similarity metric baru, dan reranker baru dalam satu release menyulitkan diagnosis regression. Versioning seluruh pipeline diperlukan jika perubahan harus dikirim bersama.

Membandingkan raw similarity score lintas model. Distribusi score dapat berubah. Nilai cosine 0.75 dari satu model tidak dijamin memiliki makna relevance yang sama pada model lain. Kalibrasi ulang threshold.

Menghapus index lama terlalu cepat. Offline test tidak menyingkirkan kemungkinan production regression. Pertahankan rollback path selama periode yang sesuai.

Mengabaikan content baru selama backfill. Snapshot yang sempurna tetap dapat tidak lengkap saat cutover. Rekonsiliasi perubahan selama migration window.

Ketahui kapan full migration tidak diperlukan

Jika hanya implementasi vector search yang berubah sementara stored vector dan scoring semantics tetap sama, struktur index mungkin dapat dibangun ulang tanpa re-embedding. Jika hanya downstream reranker yang berubah, embedding space tidak berubah. Jika hanya metadata filter ditambah, data migration mungkin diperlukan untuk metadata tetapi bukan embedding.

Pertanyaan penentunya: apakah fungsi yang memetakan source content ke vector coordinate berubah? Jika ya, anggap stored vector memerlukan migrasi yang sesuai kecuali kompatibilitas merupakan properti eksplisit representasi baru dan telah divalidasi.

Gunakan checklist migrasi yang melindungi invariant

  1. Tetapkan definisi eksplisit representation version lama dan baru.
  2. Jaga model, preprocessing, dimensions, metric, dan chunking metadata tetap dapat diaudit.
  3. Bangun index baru terpisah dari authoritative source content.
  4. Rekonsiliasi write selama backfill.
  5. Validasi record count dan failed embedding job.
  6. Bandingkan retrieval lama dan baru pada labeled evaluation set dan slice penting yang sama.
  7. Ukur embedding latency, search latency, storage, dan migration cost.
  8. Jalankan end-to-end evaluation untuk aplikasi seperti RAG.
  9. Shadow traffic representatif bila sesuai.
  10. Alihkan query model dan matching index secara atomik.
  11. Monitor versi baru dan pertahankan rollback path yang sudah diuji selama window yang sesuai.

Checklist ini menjaga satu invariant utama: search request harus membandingkan vektor yang berada dalam representation space yang sama.

Penutup

Upgrade model embedding adalah data migration, bukan sekadar perubahan konfigurasi model. Stored document vector mengodekan geometri model dan preprocessing pipeline yang membuatnya, sehingga query vector baru tidak boleh dicampur dengan index lama hanya karena dimensinya sama.

Versioning kontrak representasi, rebuild di samping index aktif, evaluasi retrieval sebelum downstream generation, rekonsiliasi write selama backfill, serta cutover query model dan index secara bersamaan membuat perubahan kualitas dapat diukur dan menyediakan rollback path yang jelas.

Kecerdasan Buatan Embedding Vector Search RAG