Apa itu vector database?

Vector database menjawab satu soalan sahaja, dengan sangat pantas

Berikan ia senarai nombor dan ia akan memulangkan senarai tersimpan yang paling hampir dengannya. Itu sahaja keseluruhan antara muka.

Senarai ini ialah embedding. Model embedding menukar satu petikan, penerangan produk atau imej kepada beberapa ratus hingga beberapa ribu nombor, diletakkan supaya makna yang serupa berada berdekatan antara satu sama lain, dan apa itu embedding dalam AI menerangkan caranya. Vector database adalah tempat senarai ini disimpan apabila anda mempunyai banyak daripadanya. Ia menyimpan setiap satu dengan ID dan beberapa metadata, membina indeks ke atasnya, dan menjawab carian jiran terdekat: "ini vektor pertanyaan, berikan saya sepuluh yang paling hampir."

Bahagian yang sukar ialah perkataan pantas. Membandingkan satu pertanyaan dengan sejuta vektor tersimpan yang masing-masing mempunyai 1,536 nombor adalah 1.5 bilion pendaraban, dan melakukannya pada setiap ketukan kekunci tidak boleh berskala. Jadi vector database menggunakan indeks jiran terdekat anggaran, yang paling biasa ialah HNSW, satu struktur graf daripada kertas kerja 2016 oleh Malkov dan Yashunin yang melawat beberapa ratus calon sahaja berbanding sejuta, dan memulangkan jawapan yang betul hampir setiap kali. "Hampir" itulah pertukarannya: sedikit ketepatan (recall) untuk kelajuan seribu kali ganda.

Pangkalan data sedia ada anda memadankan perkataan; vector database memadankan makna

Pangkalan data relasi mencari baris yang nilainya sepadan: WHERE customer_id = 4127. Indeks teks penuh mencari dokumen yang mengandungi perkataan: refund AND policy. Vector database mencari item yang maknanya hampir: pertanyaan "macam mana saya nak dapatkan balik duit saya" memulangkan petikan bertajuk "Returns and refunds" walaupun kedua-duanya tidak berkongsi sebarang perkataan.

Baris terakhir menunjukkan betapa kaburnya kategori ini. pgvector menambah lajur vektor dan indeks HNSW kepada Postgres biasa, dan Elasticsearch telah membawa medan vektor sejak versi 7.0 pada 2019 dan carian HNSW sejak 8.0 pada 2022. "Vector database" selalunya adalah keupayaan di dalam pangkalan data yang anda sudah jalankan, bukannya produk baharu, dan produk berdiri sendiri bersaing dari segi skala dan kehalusan operasi, bukan melakukan sesuatu yang Postgres tidak mampu.

Chat dengan dokumen anda ialah carian vektor dengan model di penghujungnya

Retrieval-augmented generation, yang diterangkan dalam apa itu RAG, mempunyai langkah carian dan langkah penulisan. Vector database adalah langkah carian.

1. Pecahkan setiap dokumen kepada petikan sebanyak beberapa ratus hingga seribu token.
2. Embed setiap petikan dan simpan vektor tersebut, bersama teks petikan dan sumbernya, dalam vector database.
3. Apabila satu soalan tiba, embed soalan itu dan minta pangkalan data untuk petikan yang paling hampir.
4. Serahkan petikan tersebut kepada model bahasa bersama soalan, dan biarkan ia menulis jawapan.

Langkah 1 dan 2 berlaku sekali sahaja, apabila dokumen ditambah. Langkah 3 dan 4 berlaku pada setiap soalan. Model bahasa tidak pernah melihat keseluruhan koleksi; ia hanya melihat lima atau sepuluh petikan yang dipilih oleh pangkalan data. Itulah sebabnya jawapan hanya sebagus carian itu sendiri: jika vektor paling hampir adalah petikan yang salah, model akan menjawab soalan yang salah dengan yakin, yang mana apa itu halusinasi AI mengelaskannya sebagai kegagalan capaian (retrieval) dan bukannya rekaan.

Bila anda memerlukannya, dan bila menghantar keseluruhan fail lebih baik

Keputusan ini bergantung pada saiz. Model hanya boleh mempertimbangkan tetingkap konteks miliknya pada satu masa, dan setiap token di dalamnya dibayar pada setiap giliran. Vector database wujud untuk meletakkan hanya bahagian yang berkaitan di hadapan model. Untuk satu dokumen yang muat, capaian (retrieval) adalah langkah yang boleh dilangkau; untuk koleksi yang tidak muat, itulah satu-satunya pilihan.

Bandingkan kos kedua-dua reka bentuk ini pada laporan 300,000 token, beberapa ratus muka surat, ditanya sepuluh soalan, dengan mendapatkan semula lima petikan 1,000 token setiap soalan. Menghantar keseluruhan fail setiap kali adalah 3 juta token input. Mendapatkan semula lima petikan 1,000 token setiap soalan adalah 50,000. Pada kadar input tersenarai dalam indeks kos model AI, diambil daripada OpenRouter pada 2026-08-20, jurangnya ialah 60x pada setiap model. Caching prompt, di mana penyedia menawarkannya, mengenakan bayaran bacaan semula fail yang sama pada satu persepuluh hingga separuh daripada kadar tersenarai, yang mengecilkan jurang kepada kira-kira 6x hingga 30x. Capaian (retrieval) masih menang, tetapi dengan margin yang lebih kecil.

Reka bentuk keseluruhan fail memberikan sesuatu untuk wang itu apabila fail muat dalam bajet: satu kontrak 60 muka surat, kira-kira 40,000 token, membolehkan model menjawab soalan yang memerlukan keseluruhan dokumen sekali gus, seperti "adakah sesuatu di sini bercanggah dengan klausa 14", yang tidak boleh ditanya oleh capaian (retrieval) kerana ia tidak pernah melihat klausa 14 dan percanggahan itu dalam kelompok yang sama. Peraturan yang terhasil: satu dokumen, atau beberapa dokumen sahaja, dihantar secara keseluruhan; sebuah perpustakaan melalui vector database. Antara kedua-dua, pecahkan muat naik mengikut topik supaya model mendapat bahagian yang diperlukannya.

Whizi menghantar teks itu sendiri, sehingga giliran 40,000 token

Whizi tidak menjalankan vector database untuk chat anda. Apabila anda melampirkan fail, laluan muat naik dokumen mengekstrak teks tersebut dan menghantarnya kepada model sebagai teks prompt, sehingga bajet tetap 40,000 token setiap giliran; muat naik yang lebih panjang akan dipotong, dengan satu toast dan penanda dalam mesej yang menyatakannya. Fail projek berfungsi dengan cara yang sama: ciri projek menyematkan sehingga 10 fail dan membina semula teks fail-fail tersebut ke dalam prompt pada setiap mesej, dihadkan pada 32,000 aksara setiap fail dan 120,000 untuk keseluruhan blok projek.

Had ini adalah sempadan reka bentuk. Fail yang disematkan melebihi 32,000 aksara akan dipendekkan, lampiran yang melebihi bajet giliran 40,000 token akan dipotong, dan projek adalah folder, bukan perpustakaan yang boleh dicari. Pertukaran ini disengajakan: untuk kontrak atau kertas kerja yang muat dalam bajet giliran, memiliki teks itu hadir lebih baik daripada mencarinya, dan pemeriksaan yang penting, iaitu meminta model memetik petikan yang digunakannya, berfungsi kerana petikan itu memang ada. Untuk seribu dokumen, vector database adalah alat yang betul dan aplikasi chat adalah alat yang salah.

Dua tabiat terbawa daripada mekanisme ini. Namakan fail dalam soalan anda apabila beberapa fail dilampirkan, kerana model akan memilih secara senyap jika tidak. Dan untuk mana-mana jawapan yang akan anda gunakan, minta petikan itu. Sistem capaian boleh memulangkan petikan yang salah; sistem fail-penuh boleh menjawab daripada ingatannya dan bukan daripada fail. Petikan itu menangkap kedua-duanya.