Berhenti Melakukan Chunking seperti Tahun 2022 — Yuval Belfer, AI21 Labs
AAI Engineer
컴퓨터/소프트웨어AI/미래기술
스크립트
00:00:00Halo semuanya. Terima kasih sudah hadir hari ini. Selamat datang di presentasi tentang ketiadaan. Maaf, maksudnya tentang
00:00:21retrieval. Nama saya Yuval. Saya bekerja di AI21, yang pada dasarnya adalah lab riset AI. Dan hari ini,
00:00:29saya ingin membahas topik yang enggan dibicarakan kebanyakan orang, yaitu chunking.
00:00:37Dan di akhir sesi, saya berharap bisa meyakinkan Anda bahwa chunking belum mati dan masih ada hal yang bisa kita lakukan.
00:00:45Jika Anda aktif di X, LinkedIn, atau platform mana pun, Anda mungkin sering melihat kabar bahwa RAG sudah mati, bukan?
00:00:53Belakangan ini orang-orang juga menganggap MCP tamat. Dan RAG dinyatakan mati lagi. Jayalah retrieval organik,
00:01:00pencarian organik. Sampai-sampai Anda harus bertanya, berapa kali lagi RAG bisa mati?
00:01:07Benar, kan? Bahkan ketika seseorang membela, “RAG belum mati,” seperti kata Jerry, CEO LlamaIndex,
00:01:14mereka tetap harus menyingkirkan sesuatu. Dan tampaknya, hal itu adalah chunking. Seolah-olah: jangan buang waktu di sini,
00:01:23jangan lakukan itu. Alasan orang menganggap chunking sudah usang adalah karena semua beralih ke
00:01:30agentic search sekarang, kan? Ada grep, ls, find. Semua perintah itu memang hebat,
00:01:36tetapi itu masih belum cukup jika data Anda sangat besar dan jenis kuerinya amat beragam.
00:01:46Tunggu sebentar. Oke. Menurut saya, alasan utama banyak orang enggan membahas
00:01:51chunking adalah karena prosesnya membosankan. Di setiap sistem RAG atau sistem file,
00:02:00ada dua tahapan. Tahap pertama adalah tahap yang menjemukan, jika boleh dibilang begitu. Tahap di awal,
00:02:07Anda memiliki banyak data. Anda harus melakukan prapemrosesan. Menentukan ukuran chunk. Lalu Anda
00:02:13harus menyimpan semuanya ke dalam database vektor. Bagian lainnya adalah proses retrieval, yang pada dasarnya
00:02:20dijalankan untuk setiap kueri. Ini jauh lebih mudah dilakukan, bukan? Jauh lebih mudah
00:02:25untuk dioptimalkan. Anda bisa memakai semua kueri, lalu mengubah nilai max K, maaf, top K, atau mencoba
00:02:32metode hybrid search, hal-hal semacam itu. Melakukan tuning retrieval jauh lebih menyenangkan, kan?
00:02:40Jadi, argumen saya adalah jika memang ada yang harus dihilangkan atau dianggap mati, mungkin
00:02:47hal itu adalah tuning retrieval. Ya, agentic search mungkin sudah menggantikannya. Namun, sekalipun kita
00:02:55menerima kenyataan bahwa ia menggeser tuning retrieval, performanya tetap kurang memadai saat menghadapi volume data
00:03:02yang masif. Biayanya sangat mahal. Rasanya saya tidak perlu mengingatkan hal itu lagi. Token maxing
00:03:09kini menjadi topik hangat di mana-mana. Dan masalah mendasarnya adalah, jika data itu sendiri
00:03:17tidak tertata dengan benar di folder atau direktori Anda, hasilnya tetap akan
00:03:25tidak efisien. Mari kita ambil contoh aktual. Piala Dunia FIFA sedang berlangsung. Dan bayangkan
00:03:33kita punya dataset yang memuat seluruh edisi Piala Dunia. Katakanlah setiap direktori mewakili
00:03:40edisi 1998, 2002, dan seterusnya. Namun, jika kueri Anda berbunyi: tim mana yang paling banyak memenangkan
00:03:50Piala Dunia? Anda tidak bisa hanya membuka satu folder. Anda harus memeriksa setiap folder, melihat pemenangnya,
00:03:57lalu menggabungkan data tersebut, yang tentunya sangat tidak efisien. Jawabannya jelas Brasil, setidaknya
00:04:03sampai saat pembicaraan ini berlangsung. Jadi, sebenarnya retrieval tidaklah mati. Kita tidak sedang
00:04:13mematikan apa pun di sini. Perannya kini bergeser menjadi pekerjaan infrastruktur dasar. Dan saya rasa siapa pun yang pernah
00:04:21membangun sistem RAG pasti familier. Pada hari pertama, minggu pertama, atau bahkan bulan pertama jika Anda sangat teliti,
00:04:29Anda akan menentukan ukuran chunk tertentu. Misalnya 512. Dan mungkin Anda menambahkan sedikit overlap,
00:04:36katakanlah 10% atau 20%, mengindeks semuanya, lalu melupakannya begitu saja. Dan tentu saja,
00:04:43kita sering membahas strategi chunking ukuran tetap, di mana jika ukuran chunk Anda terlalu besar,
00:04:49Anda memang mendapat gambaran utuh, itu bagus, tetapi Anda kehilangan banyak nuansa detail. Dan seluruh
00:04:54chunk tidak akan menghasilkan embedding yang bermakna. Sebaliknya, jika ukuran chunk dipilih terlalu kecil,
00:05:00konteks gambaran besarnya akan hilang. Dan prosesnya tidak akan seefisien itu. Hal ini menunjukkan kepada kita
00:05:07bahwa chunking pada dasarnya adalah kompresi lossy. Apa pun yang kita lakukan, pasti ada informasi yang terbuang.
00:05:15Dan saya tegaskan, tidak ada ukuran chunk yang mutlak benar. Banyak dari Anda yang mengolah data mungkin berkata,
00:05:23“Tetapi kami punya korpus dan dataset khusus, dan kami sudah mengoptimalkan sistem kami agar
00:05:29bekerja sangat baik pada data ini.” Awalnya kami pun berpikir demikian. Kami punya banyak pengalaman,
00:05:35dengan berbagai jenis agen, sistem, dan alur kerja yang bisa diuji,
00:05:40dan Anda tahu, sangat mudah bagi sebuah model untuk mengalami overfitting pada suatu tolok ukur.
00:05:48Namun tidak demikian pada RAG. Hal itu tidak berlaku di sana. Anda tidak bisa benar-benar mengoptimalkannya per dataset. Dan saya
00:05:54akan menunjukkan bahwa ini sebenarnya bergantung pada kueri. Mengapa saya bisa seyakin itu menyatakan hal tersebut?
00:06:00Karena kami telah menjalankan eksperimen dan mengujinya, dan sekarang saya akan mempresentasikannya. Jadi, alih-alih
00:06:06menebak ukuran chunk terbaik untuk setiap data, kami langsung membuktikannya. Kami mengambil
00:06:14sebuah dataset dan menduplikasinya beberapa kali. Dalam kasus ini, enam kali. Pada setiap duplikasi,
00:06:23di setiap instans, ukuran chunk dibuat berbeda. Ada database dengan ukuran chunk 2.000,
00:06:28ada database dengan ukuran chunk 1.000, dan seterusnya. Kami mengujinya pada beberapa dataset,
00:06:36seperti QMSUM yang berisi transkrip rapat. NarrativeQA yang berisi tanya jawab seputar
00:06:41novel. Serta dataset Seinfeld, semacam trivia tentang hal sepele. Lebih tepatnya, pertanyaan trivia
00:06:49berdasarkan transkrip serial Seinfeld. Semacam dataset iseng yang kami buat secara internal. Kami juga
00:06:56mempublikasikannya jika ada yang menginginkan tautannya di akhir nanti. Kami menguji semuanya untuk melihat apa yang terjadi.
00:07:03Pertama-tama, kami hanya ingin melihat ukuran chunk mana yang paling optimal untuk tiap dataset. Dan apa
00:07:10yang kita lihat di sini adalah contoh dari dataset Seinfeld, di mana dua kueri yang memiliki
00:07:16karakter berbeda memperoleh hasil yang berbeda bergantung pada ukuran chunk tersebut. Pertanyaan pertama, apa
00:07:24nama kemeja favorit Jerry? Bisa dilihat, ini pertanyaan yang sangat terfokus dan spesifik.
00:07:28Jawabannya kemungkinan besar sangat ringkas. Dan ini jenis kueri di mana ukuran chunk yang lebih kecil
00:07:33akan bekerja paling baik. Terlihat perbandingan peringkat 1 versus peringkat di bawah 50, antara ukuran tetap
00:07:43100 token dengan chunk yang lebih besar. Sebaliknya, pertanyaan seperti, siapa yang digambarkan Jerry sebagai musuh bebuyutannya dan sosok jahat murni,
00:07:50saya sendiri bukan penggemar berat Seinfeld, tapi saya tahu jawabannya Newman. Namun jika Anda mencarinya di
00:07:56transkrip, itu bukan hal yang mudah ditemukan. Hasilnya sangat bervariasi. Jika Anda memakai
00:08:02ukuran chunk kecil, Anda tidak akan menemukan jawabannya. Lalu setelah kami menjalankan
00:08:10serangkaian pengujian tersebut, kami menyadari dan berpikir: bagaimana jika ada oracle, atau semacam jin,
00:08:19yang bisa memberi tahu ukuran chunk paling ideal untuk setiap kueri saat retrieval dilakukan? Inilah
00:08:25eksperimen oracle kami. Kami ingin mengetahui seberapa besar potensi yang ada. Ini bukan berarti kami sudah
00:08:33membangun sistem jadinya di sini. Kami hanya ingin melihat potensi batas atasnya. Dan seperti yang terlihat
00:08:38pada grafik ini, sumbu Y menunjukkan metrik recall. Semakin tinggi, semakin baik. Sedangkan
00:08:46sumbu X adalah jumlah chunk yang diambil. Jadi grafiknya membandingkan recall@k terhadap k. Garis-garis biru ini,
00:08:52meski agak sulit dibedakan, masing-masing mewakili performa ukuran chunk tetap. Sementara garis oranye adalah
00:09:01garis oracle. Untuk setiap kueri, kami mengambil hasil terbaik dari semua opsi. Dan pola ini terlihat
00:09:09di berbagai dataset. Pada banyak kasus, Anda bisa melihat garis-garis biru saling bersilangan,
00:09:16artinya memang di sebagian besar dataset, tidak ada satu ukuran chunk yang selalu mendominasi. Dan yang
00:09:24lebih menarik adalah adanya potensi yang sangat besar. Jarak yang Anda lihat antara garis oranye
00:09:30dengan seluruh garis biru cukup lebar. Ketika saya sebut lebar, peningkatannya berkisar antara 20 hingga 40 persen murni
00:09:38dari penerapan strategi chunking. Dan itu adalah strategi yang sangat sederhana. Selisih ini merupakan konsekuensi
00:09:47dari keputusan memilih 512, 1.000, atau angka berapa pun secara arbitrer. Kerugian itulah yang harus Anda tanggung. Dan
00:09:56permasalahannya cukup rumit, karena ini semacam kendala informasi di mana kita tidak memiliki informasi yang memadai
00:10:07di setiap tahapannya. Apa maksudnya? Jika melihat tahap pengindeksan,
00:10:12di mana kita memegang kendali atas ukuran chunk, kita belum tahu apa kueri yang akan masuk.
00:10:18Kita bisa menebak, memperkirakan, atau mencoba-coba. Namun kita tidak tahu pasti kuerinya, sehingga mustahil
00:10:25menyesuaikan ukuran chunk dengan tepat. Sebaliknya di tahap retrieval, saat kueri sudah ada,
00:10:31kita tidak bisa lagi mengubah ukuran chunk karena sudah terkunci permanen. Dan tentu saja kita tidak mungkin mengulang
00:10:37seluruh proses dari awal untuk setiap kueri. Kami mempelajari riset terdahulu, seperti contextual retrieval dari Anthropic,
00:10:47di mana mereka memperkaya setiap chunk, serta metode lain yang berupaya menyempurnakan representasi laten
00:10:54dari tiap chunk. Namun bukan pendekatan itu yang kami pilih. Semuanya masih terpaku pada paradigma
00:11:01menggunakan ukuran chunk tetap, sedangkan pendekatan kami berbeda. Pertanyaan kami: mengapa harus terpaku pada satu ukuran
00:11:08jika kita bisa menggunakan beberapa ukuran sekaligus? Kami menyebutnya multi-scale indexing. Pada dasarnya,
00:11:16kami menerapkan eksperimen sebelumnya: mengambil database, menduplikasinya, lalu memecahnya dengan beberapa
00:11:26variasi ukuran chunk atau window size. Ini dilakukan saat proses pengindeksan. Lalu saat retrieval berlangsung,
00:11:34kami melakukan pencarian ke semua versi tersebut. Jika ada n duplikasi database dan ukuran jendela, maka kami perlu menjalankan
00:11:43enam panggilan retrieval berbeda untuk setiap kueri, di mana n bernilai enam. Lalu bagaimana menggabungkannya? Kita jelas tidak bisa
00:11:52menggunakan oracle, bukan? Oracle hanya dipakai untuk mengukur potensi teoretis. Pada kondisi nyata,
00:11:57kita tidak mengetahui jawabannya terlebih dahulu. Namun yang bisa kita lakukan adalah merancang algoritma penggabungan. Pertanyaannya,
00:12:06apa kendala yang mungkin timbul dari pendekatan ini? Masalahnya adalah kita memperoleh n pemeringkatan,
00:12:13tetapi peringkat tersebut berbasis chunk. Padahal chunk dengan ukuran yang berbeda tidak bisa langsung dibandingkan secara adil,
00:12:19bukan? Maka kami memilih metode yang kini sangat populer. Sebagian besar
00:12:25Sistem RAG sebenarnya bekerja seperti ini, yaitu alih-alih hanya mengambil chunk, saat kita mendapatkan
00:12:30sebuah chunk, kita mengambil seluruh dokumennya, bukan? Ketika context window membesar, kita ingin memberikan lebih
00:12:35banyak konteks. Dan sekarang, dalam kasus ini, kita memiliki n peringkat untuk dokumen yang sama, karena ini
00:12:44bukan lagi chunk. Dan ini bisa kita bandingkan. Dalam kasus ini, Anda bisa menganggap retrieval pada dasarnya
00:12:50hanyalah voting. Paham? Jadi ini bukan murni perankingan. Kita tidak memiliki satu ranking lalu melakukan
00:12:56re-rank. Kita memiliki n peringkat berbeda dari dokumen-dokumen yang relevan, dan kita ingin menggabungkan
00:13:03semuanya menjadi satu. Itulah mengapa kita menggunakan metode RRF, Reciprocal Rank Fusion, yang sebenarnya
00:13:11hanyalah rumus sederhana. Kami mencoba beberapa cara. Ini yang bekerja paling baik. Dan seperti yang Anda lihat, ini bukan
00:13:17sebuah model. Ini bukan sesuatu yang harus Anda buat secara rumit. Maksudnya, ini hanyalah
00:13:23skrip sederhana yang hampir tidak memakan waktu. Dan beginilah tampilan sistem lengkapnya. Jadi kita melakukan
00:13:32pengindeksan n kali, lalu menjalankan setiap kueri dari setiap basis data, dan menggunakan RRF untuk menggabungkan
00:13:40semuanya. Dan hasilnya, Anda bisa menebak bahwa hasilnya sangat bagus. Kalau tidak, saya tidak akan berdiri di sini dan
00:13:48terlalu percaya diri. Ya, kan? Tapi Anda bisa lihat, kami mengujinya di beberapa dataset: QMSum,
00:13:56Narrative QA, Seinfeld, dan juga FinanceBench. Kami menguji semuanya, dan hasilnya menyamai atau melampaui
00:14:05ukuran tetap terbaik. Mari kita lihat grafiknya. Agak sulit dilihat di sini, jadi saya jelaskan perlahan. Setiap baris
00:14:12di sini adalah ukuran chunk. Anda bisa melihat 50, 100, dan seterusnya. Baris terbawah adalah metode kami. Yang ini, yang
00:14:21mengambil dari semuanya lalu digabungkan. Dan setiap kolom adalah recall pada nilai tertentu. Jadi recall@1,
00:14:312, 3, hingga 10. Yang bisa Anda lihat di sini ada dua hal, bukan? Pertama, di seluruh
00:14:39tingkat recall mana pun, metode kami tetap unggul, yang mungkin terdengar sangat mudah, tetapi kenyataan bahwa Anda
00:14:46harus menggabungkan semuanya bukanlah hal yang sepele. Dan Anda juga bisa melihat bahwa kualitasnya
00:14:53benar-benar meningkat. Pada heatmap, Anda bisa melihat warnanya menjadi jauh lebih hijau. Dan sekali lagi, ini hanya
00:14:58sesuatu yang ingin saya tunjukkan secara garis besar. Di sini Anda bisa melihat keempat dataset yang menunjukkan
00:15:06hasil kami lebih baik. Peningkatannya mencapai 20, 30, bahkan 40 persen di banyak hal. Ada juga hasil
00:15:14yang belum saya tampilkan di sini, yaitu pada MTEB. Anda bisa melihatnya di blog kami, nanti saya cantumkan tautannya, kami memperoleh
00:15:22banyak peningkatan di sana juga, berkisar antara 10 hingga 40 persen tergantung datasetnya.
00:15:30Sekarang, saya tidak naif. Saya tidak akan mengklaim di sini bahwa ini tanpa biaya. Jelas ada konsekuensi biayanya,
00:15:36bukan? Tidak ada makan siang gratis. Semuanya butuh pengorbanan. Dan ya, biayanya berupa memori ekstra.
00:15:43Biayanya antara 2 hingga 5, O(1), kan? Memori tambahan konstan di mana Anda harus menyimpan
00:15:51semua salinan basis data tersebut. Namun, jika Anda memikirkannya dari segi latensi, hal ini sebenarnya tidak
00:15:59terlalu berpengaruh karena proses retrieval dapat dijalankan secara paralel. Dan tahap RRF juga tidak memakan banyak waktu.
00:16:10Menurut saya ini adalah proyek penelitian yang sangat menarik yang kami kerjakan dan kami mendapatkan hasil yang luar biasa keren.
00:16:16Masih ada hal yang harus dikerjakan, kan? Ada ruang untuk perbaikan. Ada rencana ke depan. Lebih tepatnya,
00:16:23kami ingin memahami berapa banyak ukuran chunk yang dibutuhkan dan mana saja pilihannya, ya? Fakta bahwa kami menggunakan 50, 100,
00:16:32200, dan seterusnya sejujurnya cukup arbitrer. Jadi kami memang perlu mencari tahu cara menghitungnya dan
00:16:40mengetahui berapa banyak salinan persisnya yang dibutuhkan. Lalu melangkah lebih jauh dari RRF. Alasan kami
00:16:46menggunakan RRF adalah karena metode itu bekerja paling baik dari yang kami coba, tetapi bukan berarti tidak ada
00:16:52metode yang lebih baik. Dan jika ada satu hal yang ingin saya tekankan, agen AI tidak mematikan
00:16:59retrieval. Tidak ada yang mati. Ayolah. Ini hanyalah infrastruktur. Dan bagian buruknya adalah ini
00:17:07infrastruktur dari tahun 2022. Dengan metode yang sangat sederhana, Anda dapat meningkatkan sistem RAG atau apa pun yang berhubungan
00:17:17dengan penyimpanan data dan retrieval sebesar 20 hingga 40 persen, sekali lagi, tanpa sesuatu yang terlalu
00:17:26canggih atau rumit. Jika ingin membaca lebih lanjut tentang ini, Anda bisa membaca blognya. Di sana juga ada contoh
00:17:34kode dan dataset Seinfeld. Sekian dari saya. Saya Yuval. Terima kasih banyak sudah hadir.
00:17:47Sampai jumpa di lain kesempatan.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기