Dari Retrieval ke Hasil Terstruktur: Agregasi dan ORDER BY di Milvus 3.0

Pertimbangkan alur pencarian produk yang familier. Seorang pembeli mengunggah foto gaun, dan pencarian vektor mengambil kumpulan kandidat yang relevan dari katalog yang berisi puluhan juta produk.

Namun, halaman tersebut membutuhkan lebih dari sekadar daftar berperingkat. Halaman itu membutuhkan facet merek. Halaman itu membutuhkan pengurutan harga. Tim merchandising ingin mengetahui merek mana yang mendominasi kumpulan hasil ini, rentang harga di dalam setiap merek, dan beberapa produk representatif dari setiap grup.

Sebelum Milvus 3.0, aplikasi biasanya menangani langkah kedua itu sendiri: mengambil baris dari Milvus, mengelompokkan dan mengurutkannya di pandas atau lapisan layanan, lalu menyusun respons. Beberapa tim memelihara pipeline analitik terpisah semata-mata untuk menghitung jumlah dan distribusi atas data yang sudah berada di database vektor.

Database vektor menemukan kandidat; aplikasi harus mengubahnya menjadi hasil yang terstruktur.

Milvus 3.0 memindahkan lebih banyak pekerjaan itu ke dalam mesin retrieval. Milvus menambahkan tiga kemampuan yang saling terkait tetapi berbeda:

• Agregasi kueri menghitung count, sum, avg, min, dan max atas baris yang terfilter dan terlihat, dengan field GROUP BY opsional.
• Search Aggregation mengatur kandidat approximate nearest neighbor (ANN) yang dipertahankan ke dalam bucket, menghitung metrik per bucket, membangun bucket bertingkat, dan mengembalikan hit representatif.
• Sisi server **ORDER BY** mengurutkan hasil kueri atau kandidat ANN berdasarkan satu atau beberapa field skalar sebelum aplikasi menerimanya.

Perbedaan antara kueri dan pencarian itu penting:

Kemampuan	Data yang diringkas atau diurutkan	Bentuk hasil utama	Batas ketepatan
Agregasi kueri	Semua baris terlihat yang cocok dengan filter	Satu baris per grup, dengan nilai agregat	Tepat atas kumpulan baris terlihat milik kueri
Search Aggregation	Kandidat yang dipertahankan oleh pencarian ANN dan tahap pengelompokan	Bucket, metrik, hit representatif, dan bucket anak opsional	Approximate secara desain
Kueri ORDER BY	Baris terlihat yang cocok dengan filter	Baris terurut	Tepat atas hasil kueri yang terfilter
Pencarian ORDER BY	Kandidat ANN	Hit atau grup pencarian terurut	Tidak memperluas batas recall ANN

Artikel ini menjelaskan mengapa operasi-operasi ini sebaiknya berada di dalam database, bagaimana agregasi terdistribusi bekerja, bagaimana Search Aggregation berbeda dari Grouping Search, dan di mana semantik baru ini berhenti.

Mengapa pascapemrosesan di sisi aplikasi tidak lagi memadai

Memindahkan agregasi dan pengurutan ke aplikasi dapat terlihat seperti pilihan implementasi kecil. Pada skala besar, hal itu menciptakan tiga masalah yang lebih besar.

Aplikasi memindahkan jauh lebih banyak data daripada isi jawabannya

Misalkan sebuah dasbor operasi membutuhkan jumlah produk dan harga rata-rata untuk setiap kategori di antara dua juta baris yang tersedia dalam stok. Bahkan dengan payload kasar hanya 100 byte per baris untuk kategori, harga, primary key, dan overhead serialisasi, aplikasi harus menerima sekitar 200 MB data sebelum dapat menghitung hasilnya.

Jika katalog memiliki 200 kategori, jawabannya hanya beberapa ratus key dan angka—dalam kisaran kilobyte. Aplikasi memindahkan data beberapa orde besaran lebih banyak daripada yang dikembalikannya, membayar biaya yang sama pada setiap refresh, dan membutuhkan memori klien yang cukup untuk menahan atau melakukan streaming baris perantara.

Agregasi di dalam mesin mengubah unit perpindahan data. Baris mentah tetap berada di tempatnya. Yang melintasi node dan akhirnya keluar dari Milvus adalah kumpulan status grup parsial dan final yang jauh lebih kecil.

Pengurutan lokal halaman bukan pengurutan global

Mengurutkan setelah paginasi adalah bug kebenaran, bukan sekadar implementasi yang tidak efisien.

Jika aplikasi mengambil baris 11 hingga 20 dan hanya mengurutkan baris-baris itu berdasarkan harga, aplikasi tersebut menghasilkan urutan harga di dalam halaman itu—bukan baris 11 hingga 20 dari hasil yang diurutkan berdasarkan harga secara global. Halaman berikutnya dapat berisi produk yang lebih murah daripada setiap produk di halaman pertama.

Batas yang sama berlaku dalam pencarian vektor. Mengambil kumpulan Top-K kecil dan mengurutkannya di aplikasi hanya dapat mengubah urutan kandidat tersebut. Itu tidak dapat memulihkan kandidat relevan yang tidak dikembalikan tahap ANN, dan sering kali mendorong aplikasi untuk mengambil data berlebihan hanya agar pengurutan sisi klien berguna.

Pengurutan sisi server memberi Milvus kendali atas urutan dan rangkaian paginasi. Untuk workload kueri, mesin mengurutkan kumpulan baris yang terfilter sebelum menerapkan jendela halaman. Untuk workload pencarian, mesin mengurutkan di dalam batas kandidat ANN dan menjaga keterbatasan itu tetap eksplisit.

Klien tidak dapat mereproduksi visibilitas database

Agregasi juga bergantung pada baris mana yang terlihat pada timestamp kueri. Penghapusan, entitas kedaluwarsa, dan penulisan bersamaan diatur oleh multiversion concurrency control (MVCC) dan semantik konsistensi Milvus.

Setelah baris mentah meninggalkan database, aplikasi biasanya mengasumsikan bahwa batch yang diterima mewakili snapshot yang benar. Mere konstruksi aturan visibilitas yang sama di klien tidak praktis, terutama ketika koleksi sedang menerima penulisan dan penghapusan.

Solusi umum—mesin analitik kedua yang diberi data melalui ekspor dan ETL—menambahkan salinan data lain, batas konsistensi lain, dan pipeline lain untuk dioperasikan. Perhitungan jumlah, metrik, dan pengurutan seharusnya berjalan di tempat data dan aturan visibilitasnya sudah berada.

Sekarang, mari kita lihat apa yang ditawarkan Milvus 3.0.

Agregasi kueri: statistik tepat atas baris yang terlihat

Agregasi kueri menjawab pertanyaan seperti:

• Berapa banyak produk yang tersedia dalam stok di setiap kategori?
• Berapa harga rata-rata per merek?
• Berapa timestamp peristiwa minimum dan maksimum untuk setiap host?
• Berapa banyak rekaman yang tersisa setelah filter dan visibilitas TTL diterapkan?

API-nya terasa familier bagi siapa pun yang pernah menggunakan SQL: berikan satu atau beberapa field di group_by_fields, lalu tempatkan ekspresi agregasi di output_fields.

res = client.query(
    collection_name="products",
    filter='status == "on_sale"',
    group_by_fields=["category"],
    output_fields=["category", "count(*)", "avg(price)"],
)
# [
#     {"category": "books", "count(*)": 18734, "avg(price)": 45.3},
#     …
# ]

Sintaksnya adalah bagian yang sederhana. Model eksekusinya yang membuat hasilnya berguna di database vektor terdistribusi.

Status lokal segmen menggantikan perpindahan baris mentah

Sebuah koleksi Milvus dapat mencakup ratusan atau ribuan segmen yang didistribusikan di beberapa query node, dengan data yang baru ditulis masih berada di jalur streaming. Tidak ada satu node eksekusi pun yang sejak awal memiliki setiap baris yang terlihat.

Karena itu, Milvus mendorong agregasi turun ke segmen:

1. Setiap segmen menerapkan filter dan aturan visibilitas MVCC secara lokal.
2. Segmen memancarkan satu status parsial per grup alih-alih baris-baris yang cocok.
3. Status parsial digabungkan di dalam query node.
4. Proxy melakukan penggabungan akhir lintas node dan mengembalikan grup yang lengkap.

Jumlah data perantara kini diskalakan berdasarkan jumlah grup dan status agregat, bukan secara langsung berdasarkan jumlah baris yang cocok.

Operasi penggabungan bergantung pada agregatnya:

Agregat	Status parsial	Aturan penggabungan
count	Jumlah parsial	Tambahkan jumlah
sum	Jumlah parsial	Tambahkan jumlah
min	Minimum parsial	Ambil minimum
max	Maksimum parsial	Ambil maksimum
avg	Jumlah dan hitungan parsial	Tambahkan kedua status, lalu bagi sekali pada tahap akhir

avg adalah kasus yang instruktif. Merata-ratakan dua rata-rata parsial adalah salah ketika partisi berisi jumlah baris yang berbeda. Milvus membawa sum dan count secara independen dan menghitung rata-rata akhir hanya setelah keduanya digabungkan secara global.

Ini adalah salah satu alasan agregasi sebaiknya berada di database: operasinya bukan sekadar “menjalankan fungsi yang sama pada beberapa batch.” Mesin harus mempertahankan aljabar setiap agregat melintasi batas segmen dan node.

Visibilitas diterapkan sebelum agregasi

Baris yang dihapus dan kedaluwarsa dikeluarkan dari status parsial di tingkat segmen sesuai dengan batas visibilitas kueri. Baris-baris itu tidak dikirim ke atas lalu dikoreksi di aplikasi.

Karena itu, hasilnya menggambarkan baris yang dianggap terlihat oleh Milvus untuk permintaan tersebut, bukan kumpulan batch arbitrer yang ditarik pada waktu yang sedikit berbeda.

limit kini menghitung grup

Dalam kueri normal, limit mengontrol berapa banyak baris entitas yang dikembalikan. Dalam kueri berkelompok, parameter ini mengontrol berapa banyak grup yang dikembalikan. Karena kardinalitas hasil ditentukan oleh grup, bukan baris yang cocok, agregasi kueri juga dapat menghilangkan limit ketika membutuhkan setiap grup.

Ini terdengar seperti detail API kecil, tetapi mencerminkan model hasil yang berbeda: output bukan lagi halaman entitas. Output adalah relasi yang baris-barisnya merepresentasikan grup.

Search Aggregation: tampilan berbucket dari kandidat ANN

Agregasi kueri menjawab, “Seperti apa baris terlihat yang cocok dengan filter ini?” Search Aggregation mengajukan pertanyaan berbeda: “Seperti apa kumpulan kandidat yang diambil untuk vektor ini?”

Operasi itu tidak memiliki padanan SQL yang tepat. Pencarian ANN terlebih dahulu menetapkan batas kandidat yang didorong oleh kemiripan. Milvus kemudian mengatur kandidat yang dipertahankan berdasarkan key skalar dan mengembalikan pohon bucket alih-alih daftar hit datar biasa.

Sebuah bucket dapat berisi:

• key seperti brand atau key komposit seperti (brand, color);
• jumlah kandidat yang dipertahankan;
• metrik termasuk count, sum, avg, min, dan max;
• entitas representatif yang dipilih dengan top_hits; dan
• sub_aggregation bertingkat yang membuat bucket anak.

Untuk halaman pencarian produk, satu permintaan dapat mengembalikan bucket merek, harga rata-rata di dalam setiap bucket, dan tiga produk representatif per merek:

from pymilvus import SearchAggregation, TopHits
aggregation = SearchAggregation(
fields=[“brand”],
size=10,                                    # Return up to 10 brand buckets
metrics={“avg_price”: {“avg”: “price”}},
order=[{“_count”: “desc”}],               # Order by retained-candidate count
top_hits=TopHits(
size=3,
sort=[{“_score”: “desc”}],            # Use “asc” for L2 distance
),
)
res = client.search(
collection_name=“products”,
data=[query_vector],
anns_field=“embedding”,
search_aggregation=aggregation,
output_fields=[“title”, “brand”, “price”],
)
buckets = res.agg_buckets[0]

Ketika search_aggregation ditetapkan, daftar hit biasa kosong. Aplikasi membaca respons bucket dari result.agg_buckets.

Spesifikasi agregasi menetapkan dua batas yang berbeda

Search Aggregation tidak menjalankan GROUP BY atas setiap entitas dalam koleksi, dan tidak sekadar mengambil respons Top-K biasa lalu mengagregasi daftar datar tersebut.

Eksekusinya memiliki tiga tahap:

1. Milvus menjalankan pencarian ANN untuk mengambil kandidat di dekat vektor kueri.
2. Tahap pengelompokan mempertahankan jumlah kandidat yang dibatasi untuk setiap key bucket penuh.
3. Milvus membangun bucket, menghitung metrik atas kandidat yang dipertahankan, mengurutkan bucket, dan melampirkan hit representatif atau bucket anak.

Dua parameter mengontrol bagian hasil yang berbeda:

• SearchAggregation.size membatasi berapa banyak bucket yang dikembalikan pada tingkat agregasi tersebut.
• TopHits.size terbesar di mana pun dalam pohon agregasi menetapkan anggaran kandidat yang dipertahankan untuk setiap key komposit penuh. Jika permintaan tidak berisi top_hits, anggaran per key default menjadi satu.

limit pencarian tingkat atas tidak mengontrol mode ini dan diabaikan ketika search_aggregation ada.

Perbedaan itu penting saat membaca count atau metrik sebuah bucket. Dengan TopHits(size=3), sebuah bucket merek dapat merangkum paling banyak tiga kandidat yang dipertahankan untuk key penuhnya, bahkan jika koleksi berisi ribuan produk relevan dari merek tersebut. Meningkatkan TopHits.size memperlebar jendela metrik per key, tetapi tidak mengubah pencarian ANN menjadi pemindaian tepat.

Jika aplikasi membutuhkan statistik tepat atas setiap baris terlihat yang cocok dengan filter, aplikasi sebaiknya menggunakan agregasi kueri. Search Aggregation ditujukan untuk mendeskripsikan dan membandingkan kandidat yang dihasilkan oleh retrieval berbasis kemiripan.

Search Aggregation dan Grouping Search memecahkan masalah yang berbeda

Milvus telah mendukung Grouping Search (group_by)sejak Milvus 2.4. Mudah untuk melihat kata “grouping” pada kedua fitur dan mengasumsikan keduanya adalah dua antarmuka untuk operasi yang sama. Kontrak output keduanya berbeda.

Grouping Search mengubah entitas mana yang muncul dalam daftar hasil berperingkat. Pola RAG umum menyimpan chunk sebagai entitas individual, mengelompokkannya berdasarkan doc_id, dan mengembalikan satu atau beberapa chunk dari setiap dokumen. Output utama tetap berupa hit pencarian biasa, tetapi dengan lebih sedikit nilai berulang dari field pengelompokan.

Search Aggregation mengembalikan tampilan statistik. Output utamanya adalah pohon bucket yang berisi key, jumlah, metrik, hit representatif, dan bucket anak opsional.

Kebutuhan aplikasi	Lebih baik gunakan	Konsumsi
Daftar entitas berperingkat dengan keberagaman lebih besar di suatu field	Grouping Search	Hit pencarian biasa
Jumlah facet, metrik per grup, hit representatif, atau distribusi bertingkat	Search Aggregation	Objek AggregationBucket di result.agg_buckets

Aturan praktisnya adalah mulai dari bentuk respons UI atau API. Jika aplikasi merender daftar, Grouping Search biasanya merupakan primitif yang tepat. Jika aplikasi merender facet, kartu distribusi, atau hierarki grup, gunakan Search Aggregation.

Kedua mode saling eksklusif dalam satu permintaan karena keduanya mendefinisikan bentuk hasil utama yang berbeda.

ORDER BY: pindahkan pengurutan sebelum batas aplikasi

Pengurutan adalah fitur yang paling tidak eksotis dalam rilis ini dan salah satu yang paling mudah diimplementasikan secara keliru di luar mesin.

Milvus 3.0 mengekspos pengurutan pada kueri maupun pencarian, tetapi kedua jalur menggunakan parameter SDK yang berbeda dan beroperasi atas kumpulan input yang berbeda.

Pengurutan kueri mengurutkan kumpulan baris yang terfilter

Kueri PyMilvus menggunakan order_by, yang diekspresikan sebagai daftar string "field:direction". Mesin menerapkan filter, mengurutkan baris yang terlihat, lalu menerapkan limit dan offset.

res = client.query(
    collection_name="products",
    filter='category == "books"',
    output_fields=["title", "price"],
    order_by=["price:desc", "title:asc"],
    limit=10,
    offset=10,  # Rows 11-20 in the filtered, price-sorted result
)

Ini membuat kueri berguna untuk penelusuran yang diurutkan secara bisnis: rekaman terbaru yang diingest, produk berharga tertinggi di dalam filter, inventaris terendah, atau nilai ekstrem untuk inspeksi data. Tanpa pengurutan sisi server, aplikasi harus mengambil baris terlebih dahulu dan tidak dapat mendefinisikan urutan bisnis yang andal lintas halaman.

Untuk field kueri yang nullable, urutan naik menempatkan null di akhir dan urutan turun menempatkannya di awal. Field pengurutan tidak harus muncul di output_fields; sertakan hanya ketika aplikasi membutuhkan nilainya dalam respons.

Pengurutan pencarian mengubah urutan kumpulan kandidat ANN

Pencarian PyMilvus menggunakan order_by_fields, dengan setiap entri menamai field skalar dan arahnya:

res = client.search(
    collection_name="products",
    data=[query_vector],
    anns_field="embedding",
    limit=50,
    output_fields=["title", "price"],
    order_by_fields=[
        {"field": "price", "order": "asc"},
    ],
)

ANN tetap menentukan entitas mana yang menjadi kandidat. order_by_fields mengubah bagaimana kandidat tersebut dikembalikan; ini tidak membuat pencarian memindai koleksi secara global untuk produk termurah.

Batas itu memberi kedua API pekerjaan yang berbeda:

• Gunakan kueri plus order_by ketika urutan skalar itu sendiri mendefinisikan hasil, seperti sepuluh produk termurah yang tersedia dalam stok.
• Gunakan pencarian plus order_by_fields ketika relevansi semantik atau vektor mendefinisikan kumpulan kandidat dan field skalar menentukan bagaimana kandidat tersebut harus disajikan.

Pengurutan multi-field menerapkan key sesuai urutan daftar. Ketika kandidat pencarian memiliki nilai yang sama untuk setiap key skalar yang ditentukan, Milvus mempertahankan urutan skor kemiripan aslinya.

Pengurutan juga dapat dikomposisikan dengan Grouping Search. Milvus mengurutkan grup berdasarkan nilai skalar yang dikonfigurasi dari entitas teratas setiap grup sambil mempertahankan bentuk hasil berkelompok. Ini berguna ketika aplikasi menginginkan keberagaman lintas field sekaligus urutan grup yang relevan secara bisnis.

Apa yang dimungkinkan oleh kemampuan-kemampuan ini

API ini adalah primitif database umum, tetapi beberapa workload retrieval langsung mendapat manfaat.

RAG dan agen: inspeksi konsentrasi retrieval

Sistem RAG atau agentic dapat membucketkan chunk yang diambil berdasarkan dokumen sumber, lini produk, tenant, atau tipe konten. Hasil yang terkonsentrasi di dua dokumen membawa sinyal cakupan yang berbeda dari hasil yang tersebar di puluhan sumber.

Distribusi itu bukan jaminan kualitas jawaban. Namun, distribusi tersebut merupakan diagnostik retrieval yang berguna yang dapat dikombinasikan oleh aplikasi atau agen dengan skor, sitasi, dan pemeriksaan lain saat memutuskan apakah akan memperluas kueri, mengambil ulang, atau meminta klarifikasi.

Grouping Search tetap menjadi pilihan yang tepat ketika tujuannya hanya untuk mendiversifikasi chunk yang dikembalikan. Search Aggregation berguna ketika sistem membutuhkan distribusi itu sendiri.

E-commerce dan rekomendasi konten: kembalikan facet bersama pencarian

Halaman pencarian produk pembuka dapat menerima bucket merek, metrik harga, item representatif, dan daftar kandidat yang diurutkan secara skalar dari Milvus. Aplikasi tetap mengontrol presentasi dan logika bisnis, tetapi tidak lagi perlu merekonstruksi semantik bucket dasar dari hit yang diekspor.

Log dan keamanan: gabungkan kemiripan dengan distribusi insiden

Pencarian kemiripan dapat menemukan peristiwa yang terkait dengan baris log mencurigakan. Search Aggregation kemudian dapat menunjukkan host mana yang mendominasi kandidat tersebut, timestamp minimum dan maksimum dalam setiap bucket host, atau bagaimana kandidat terbagi berdasarkan tingkat keparahan dan layanan.

Hasilnya tetap merupakan tampilan atas kandidat yang diambil, bukan jumlah insiden global yang tepat. Ketika investigasi membutuhkan jumlah tepat atas setiap peristiwa yang cocok dengan filter, agregasi kueri menyediakan jalur kedua itu.

Operasi dan eksplorasi data: hitung alih-alih ekspor

Dasbor dan alat administratif dapat menjalankan perhitungan jumlah dan rata-rata yang tepat atas baris terfilter, lalu menelusuri entitas yang mendasarinya dalam urutan skalar yang terdefinisi. Ini menghilangkan banyak utilitas sekali pakai “ekspor, hitung, dan urutkan” tanpa berpura-pura bahwa Milvus telah menjadi database analitik penuh.

Batasan: apa yang tidak digantikan oleh agregasi dan ORDER BY

Fitur-fitur ini memperluas mesin retrieval; fitur-fitur ini tidak mengubah Milvus menjadi sistem online analytical processing (OLAP).

• Agregasi kueri mendukung pengelompokan plus count, sum, avg, min, dan max. Ini tidak menambahkan join, window function, atau subquery kompleks. Pekerjaan analitik offline berskala besar tetap sebaiknya berada di sistem seperti Spark, yang dapat bekerja dengan snapshot Milvus 3.0 dan jalur penyimpanan bersama.
• Key grup kueri mendukung field integer, VARCHAR, dan TIMESTAMPTZ. Key bucket Search Aggregation juga mendukung field Boolean. Nilai floating-point, vektor, JSON, dan array bukan key bucket.
• Untuk Search Aggregation, count menerima "*" atau sumber non-JSON, non-dinamis; sum dan avg memerlukan sumber numerik; dan min serta max juga mendukung sumber string dan TIMESTAMPTZ. Agregasi kueri mengikuti batas tipe aritmetika yang sama. Konsultasikan panduan API sebelum menerapkan agregat ke tipe field kompleks.
• Agregasi kueri dapat mengurutkan output berkelompok berdasarkan key grup, sementara pengurutan berdasarkan agregat terhitung seperti count(*) masih menjadi batasan saat ini. Tanpa urutan eksplisit, urutan grup tidak dijamin.
• Search Aggregation saat ini tidak dapat digabungkan dengan Hybrid Search, Grouping Search, Search Iterators, offset non-nol, atau highlighting dalam permintaan yang sama.
• Jumlah dan metrik Search Aggregation menggambarkan kandidat ANN yang dipertahankan, bukan koleksi lengkap dan bukan setiap entitas yang mungkin relevan secara semantik.
• ORDER BY pencarian mengubah presentasi kandidat. Ini tidak memperbaiki kandidat ANN yang terlewat atau mengubah retrieval berbasis kemiripan menjadi kueri Top-N skalar yang tepat.

Cara paling jelas untuk memilih di antara primitif baru ini adalah memulai dari pertanyaannya:

• Untuk statistik tepat atas baris terlihat yang terfilter, gunakan agregasi kueri.
• Untuk distribusi atas kandidat retrieval berbasis kemiripan, gunakan Search Aggregation.
• Untuk daftar berperingkat yang beragam, gunakan Grouping Search.
• Untuk urutan skalar yang terdefinisi, gunakan kueri atau pencarian ORDER BY sesuai jalur mana yang menetapkan kumpulan hasil.

Dari daftar kandidat ke hasil terstruktur

Database vektor secara tradisional mengoptimalkan satu pertanyaan: entitas K mana yang paling dekat dengan vektor ini?

Sistem retrieval produksi segera mengajukan pertanyaan lanjutan. Grup mana yang mendominasi hasil? Berapa jumlah dan rentangnya? Contoh mana yang merepresentasikan setiap grup? Dalam urutan bisnis apa aplikasi harus menyajikan baris atau kandidat?

Milvus 3.0 membawa operasi-operasi tersebut ke dalam mesin yang sama yang memiliki data, batas kandidat ANN, dan semantik visibilitas. Agregasi kueri melakukan reduksi terdistribusi yang tepat atas baris terlihat. Search Aggregation membangun tampilan berbucket atas kandidat ANN yang dipertahankan. ORDER BY memberi jalur kueri dan pencarian urutan skalar sisi server tanpa meminta aplikasi untuk merekonstruksinya halaman demi halaman.

Hasilnya bukan mesin OLAP yang tersembunyi di dalam database vektor. Ini adalah mesin retrieval yang dapat mengembalikan lebih banyak struktur yang benar-benar dibutuhkan aplikasi.

Coba agregasi dan ORDER BY di Milvus 3.0

Milvus 3.0 kini tersedia. Gunakan panduan Query untuk agregasi tepat dan pengurutan kueri, panduan Search Aggregation untuk semantik dan batas bucket, panduan Basic Vector Search untuk pengurutan pencarian, dan panduan Grouping Search ketika tujuan utama Anda adalah keberagaman hasil.

Untuk rilis yang lebih luas, lihat blog peluncuran Milvus 3.0, catatan rilis Milvus 3.0, dan repositori milvus-io/milvus.

Jika Anda ingin mengevaluasi API yang sama tanpa mengoperasikan cluster sendiri, cobalah di Zilliz Cloud. Referensi kueri Zilliz Cloud dan referensi pencarian saat ini menjelaskan ketersediaan dan parameter untuk tipe cluster terkelola.

Untuk mendiskusikan workload atau kasus tepi dengan tim, bergabunglah dengan komunitas Milvus Discord atau pesan sesi Milvus Office Hours.