00:00:00Mari kita selesaikan masalah clod code dan memori yang membuat sistem AI secara andal dan akurat
00:00:06menjawab pertanyaan tentang percakapan masa lalu atau tumpukan dokumen raksasa adalah masalah yang telah kami
00:00:13coba selesaikan selama bertahun-tahun dan respons tipikalnya adalah RAG, retrieval augmented generation, dan
00:00:20meskipun video ini berjudul tujuh level clod code dan RAG, inti sebenarnya dari video ini
00:00:26adalah mendekonstruksi masalah clod code dan sistem AI secara umum serta memori, dan bahkan
00:00:33yang lebih penting, video ini memberikan peta jalan yang menunjukkan di mana posisi Anda dalam
00:00:37pertarungan antara sistem AI dan memori ini serta apa yang dapat Anda lakukan untuk naik ke level berikutnya. Jadi, saat kita menelusuri
00:00:43tujuh level clod code dan RAG ini, kita akan membahas sejumlah topik, namun kita
00:00:48tidak akan memulai dari GraphRAG atau sesuatu yang rumit; kita akan mulai dari awal,
00:00:53yaitu sistem memori dasar yang asli dari clod code karena, meski menyedihkan untuk dikatakan,
00:00:59di sinilah kebanyakan orang tidak hanya memulai tetapi juga menetap, dari memori otomatis dan hal-hal seperti
00:01:04clod md, kita akan beralih ke alat eksternal seperti Obsidian sebelum akhirnya kita menemukan diri kita
00:01:10bersama para pemain besar dengan sistem RAG yang sesungguhnya; di level-level ini kita akan membahas apa itu RAG sebenarnya,
00:01:16cara kerjanya, berbagai jenis RAG seperti naive RAG vs GraphRAG vs agentic RAG, hal-hal seperti
00:01:21re-ranker dan segala sesuatu di antaranya, dan di setiap level kita akan menguraikannya dengan
00:01:25cara yang sama: kita akan membahas apa yang diharapkan di level tersebut, keterampilan yang perlu dikuasai,
00:01:29jebakan yang harus dihindari, dan apa yang perlu dilakukan untuk beralih ke level berikutnya. Video ini
00:01:34tidak akan menjadi penjelasan teknis yang super mendalam tentang cara menyiapkan sistem spesifik
00:01:40tersebut karena saya sudah melakukannya di banyak kesempatan saat kita membahas GraphRAG dan
00:01:45LightRAG misalnya, atau bahkan topik yang lebih tingkat lanjut seperti RAG apa pun dalam berbagai sistem
00:01:50embedding ini; saya telah membuat video di mana saya menguraikan dari awal hingga akhir cara
00:01:55menyiapkannya sendiri, jadi saat kita sampai di bagian itu saya akan menautkan video-video tersebut, dan ini demi
00:02:00kepentingan kita bersama agar video ini tidak berdurasi lima jam, namun untuk level-level tersebut kita tetap akan membahas
00:02:04apa artinya, apa kegunaan setiap sistem, dan kapan Anda harus menggunakannya, tapi sebelum
00:02:09kita mulai dengan level satu, sepatah kata cepat dari sponsor hari ini: saya sendiri; baru bulan lalu saya merilis clod
00:02:15code master class dan ini adalah cara nomor satu untuk beralih dari nol menjadi pengembang AI, terutama jika Anda tidak berasal
00:02:21dari latar belakang teknis, dan master class ini sedikit berbeda karena kami fokus pada
00:02:25sejumlah kasus penggunaan yang berbeda untuk mempelajari cara menggunakan clod code, salah satunya adalah sesuatu seperti
00:02:31RAG tingkat produksi, cara membangun sistem RAG yang akan Anda lihat di video ini dalam skenario nyata dan
00:02:37benar-benar menggunakannya sebagai anggota tim atau menjualnya ke klien, itulah hal-hal yang kami fokuskan; jadi
00:02:42jika Anda ingin mendapatkan akses, Anda dapat menemukannya di dalam Chase AI Plus; ada tautan ke sana di
00:02:47komentar yang disematkan dan kami akan senang menerima Anda di sana; sekarang mari kita mulai dengan level satu, yaitu memori otomatis,
00:02:51ini adalah sistem yang secara otomatis digunakan clod code untuk menciptakan semacam aparatus memori guna
00:02:58mengingat hal-hal yang telah dibicarakan, dan Anda tahu Anda berada di sini jika Anda tidak pernah
00:03:02menyiapkan apa pun secara sengaja untuk membantu clod code mengingat konteks secara umum tentang percakapan sebelumnya
00:03:09atau hanya hal-hal yang terjadi di basis kode Anda, dan saat kita berbicara tentang memori otomatis, secara harfiah
00:03:13itulah sebutannya, sistem memori otomatis yang diaktifkan secara otomatis saat Anda menggunakan clod
00:03:18code, pada dasarnya memungkinkan clod code untuk membuat file markdown sendiri yang mencantumkan
00:03:26hal-hal yang dianggapnya penting tentang Anda dalam proyek tertentu dan ini murni didasarkan
00:03:32pada intuisinya sendiri berdasarkan percakapan Anda, dan saya dapat melihat file-file memori yang telah dibuatnya ini, sekali lagi
00:03:37ia melakukannya sendiri; jika Anda masuk ke folder .clod Anda, lalu ke projects, Anda akan melihat sebuah
00:03:42folder di sana yang bernama memory, dan di dalam file itu Anda akan melihat sejumlah file markdown; di sini
00:03:47ada empat buah, dan itu seperti versi catatan tempel dari clod code yang mengatakan, "oh ya, dia pernah menyebutkan
00:03:51tentang target pertumbuhan proyek YouTube-nya sekali, mari kita tuliskan itu," dan di dalam setiap
00:03:59folder memori akan ada file memory.md; jadi Anda lihat di file memori ini ada catatan kecil tentang
00:04:04salah satu keahlian saya dan kemudian ia memiliki indeks dari semua sub-file memori ini yang menyatakan
00:04:09bahwa ada pertumbuhan YouTube di sini, pendapatan, atau referensi, dan inilah isinya; jadi jika
00:04:13saya sedang berbicara dengan clod code di file vault saya dan menyebutkan sesuatu tentang YouTube dan semacamnya
00:04:19target pertumbuhan saya, ia akan merujuk ini dan berkata, "oh ya, Chase sedang mencoba
00:04:23mendapatkan x jumlah pelanggan di akhir 2026," ini menarik tapi pada akhirnya tidak terlalu berguna,
00:04:30ini seperti saat Anda berada di dalam ChatGPT dan ia akan memunculkan hal-hal acak tentang
00:04:35percakapan sebelumnya dan seolah-olah dipaksakan masuk; rasanya seperti, "oke aku mengerti kamu ingat ini
00:04:40tapi aku tidak terlalu peduli dan sejujurnya agak aneh terus mengungkit itu, aku lebih suka jika kamu
00:04:44tidak melakukannya," dan sayangnya di sinilah kebanyakan orang berhenti dalam perjalanan memori mereka dan ini didasarkan pada
00:04:49masa lalu yang agak kasar yang kita semua alami saat menggunakan chatbot ini
00:04:54karena chatbot ini tidak memiliki memori nyata dari satu percakapan ke percakapan lainnya, sehingga
00:05:00kita selalu takut setengah mati untuk keluar dari jendela obrolan atau keluar dari sesi terminal
00:05:06karena Anda pikir, "astaga, ia tidak akan mengingat percakapan saya," dan ini sebenarnya
00:05:10masalah nyata karena apa jawaban semua orang terhadap jendela obrolan yang tidak mampu mengingat apa pun?
00:05:17Jawabannya adalah Anda terus melanjutkan percakapan itu selamanya karena Anda tidak ingin sampai pada
00:05:22skenario di mana Anda harus keluar dan ia melupakan segalanya, ini adalah ketakutan yang lahir di sini,
00:05:26di dalam jendela obrolan ini, dimulai dengan ChatGPT dan hal yang sama dengan aplikasi web clod, dan sejujurnya dulu
00:05:31jauh lebih buruk dengan aplikasi web clod karena saya rasa kita semua ingat masa sebelum adanya
00:05:35konteks 1 juta jendela di mana Anda memiliki waktu seperti 30 menit untuk berbicara dengan clod dan berkata, "sampai
00:05:39jumpa empat jam lagi," masalahnya adalah orang-orang membawa perilaku psikotik neurotik semacam itu ke
00:05:45terminal dan apa yang mereka lakukan sebagian besar karena sekarang Anda bisa lolos dengan jendela konteks 1 juta
00:05:50adalah mereka tidak pernah menghapusnya, mereka hanya terus berbicara dan berbicara dengan clod code karena
00:05:55mereka tidak ingin ia lupa apa yang sedang mereka bicarakan karena masalah memori ini, dan
00:06:00masalahnya adalah efisiensi Anda turun drastis seiring waktu jika Anda semakin lama berbicara dengan clod code di dalam
00:06:05sesi yang sama, dan ini adalah ide fundamental dari pembusukan konteks; jika Anda tidak tahu apa itu pembusukan konteks,
00:06:10itu adalah fenomena di mana semakin sering saya menggunakan sistem AI dalam sesi yang sama, dalam obrolan yang sama,
00:06:16dan saya memenuhi jendela konteks tersebut, maka kinerjanya akan semakin buruk; Anda bisa melihatnya di sini, clod code dengan jendela
00:06:23konteks 1 juta pada 256 ribu token, alias saya baru mengisi sekitar seperempat dari jendela konteksnya, kinerjanya berada pada
00:06:3092%, di akhir turun menjadi 78%, jadi semakin sering Anda menggunakannya dalam obrolan yang sama, kinerjanya semakin buruk dan itu salah satu
00:06:36masalah utama yang dialami orang-orang dengan sistem AI dan memori; saya punya clod code, ia punya konteks satu juta
00:06:42sekarang, namun saya tidak ingin ia lupa tentang percakapan yang sedang saya lakukan jadi saya tidak pernah keluar dari
00:06:47jendelanya, saya hanya terus mengisinya, dan dua hal terjadi: satu, efektivitasnya
00:06:51menurun seperti yang baru saja Anda lihat; dua, penggunaan Anda membengkak karena jumlah token yang digunakan pada
00:06:59konteks 1 juta atau 800.000 itu jauh lebih banyak daripada konteks 80.000, jadi ini bukan satu-satunya masalah,
00:07:08tapi agak melenceng, kita berada di ekosistem saat ini di mana semua orang mengeluh tentang clod code yang
00:07:12kinerjanya menurun dan penggunaan saya habis secara otomatis; ada sejumlah alasan untuk itu tetapi salah satunya
00:07:18tidak diragukan lagi adalah fakta bahwa sejak konteks 1 juta diperkenalkan, orang-orang tidak tahu cara
00:07:24mengelola jendela konteks mereka sendiri dan mereka tidak cukup agresif dalam
00:07:29membersihkan dan mengatur ulang percakapan seperti otentikasi, tapi itu agak melenceng dari topik;
00:07:34inti dari seluruh diskusi tersebut adalah bahwa ketika berbicara tentang memori dalam diskusi tentang RAG dan
00:07:39clod code, kita harus menyimpan pembusukan konteks di dalam pikiran kita karena kita terus mencoba menangani
00:07:44ketegangan ini antara: oke saya ingin memasukkan konteks agar clod code dapat menjawab pertanyaan tentang banyak hal,
00:07:50namun di saat yang sama saya tidak ingin konteksnya menjadi terlalu besar karena itu akan memperburuk kinerjanya,
00:07:55jadi itu selalu perlu menjadi sesuatu yang kita pikirkan dalam percakapan tentang memori ini,
00:08:02tapi untuk membawa ini kembali ke video sebenarnya dan level satu: apa yang dilakukan orang di level satu?
00:08:06Jawabannya adalah mereka tidak benar-benar melakukan apa-apa dan karena mereka tidak melakukan apa-apa, mereka hanya mengandalkan
00:08:10jendela konteks yang membengkak untuk mengingat sesuatu, jadi Anda tahu Anda berada di sini ketika Anda tidak pernah mengedit
00:08:15file clod.md dan Anda tidak pernah membuat artefak atau file apa pun yang memungkinkan clod
00:08:23code menyadari apa yang sebenarnya terjadi, apa yang telah dilakukannya di masa lalu, dan apa yang perlu
00:08:27dilakukannya di masa depan; jadi apa yang perlu kita kuasai di level ini? Sebenarnya yang perlu Anda
00:08:31kuasai terlepas dari semua yang saya tulis di sini adalah Anda hanya perlu memahami bahwa memori otomatis saja tidak cukup
00:08:35dan kita perlu mengambil peran aktif terkait clod code dan memori karena jebakan di level ini
00:08:40jika Anda tidak mengambil peran aktif adalah Anda tidak memiliki kendali, dan kita perlu mengendalikan apa yang dipertimbangkan clod code
00:08:44saat ia menjawab pertanyaan kita, dan untuk membuka kunci level satu dan beralih ke level dua,
00:08:50kita butuh memori yang eksplisit dan kita perlu mencari tahu cara melakukannya, file apa
00:08:57yang perlu Anda edit dan pahami keberadaannya untuk dapat mengambil peran aktif dalam
00:09:01hubungan ini; sekarang level dua adalah tentang satu file spesifik yaitu file clod.md; saat Anda belajar
00:09:06tentang hal ini, rasanya seperti anugerah; akhirnya ada satu tempat di mana saya bisa memberitahu clod
00:09:12code beberapa aturan dan konvensi yang selalu ingin saya ikuti dan ia akan melakukannya, dan
00:09:16bahkan saya bisa menyertakan hal-hal yang ingin saya ingat dan ia akan selalu mengingatnya; ini benar-benar terasa seperti
00:09:20kemajuan pada awalnya; jadi inilah templat dari file clod.md standar untuk proyek asisten pribadi; sekarang
00:09:29clod code akan secara otomatis membuat file clod.md tetapi Anda memiliki kemampuan untuk
00:09:33mengedit atau bahkan memperbaruinya sesuai permintaan dengan menggunakan perintah seperti /init dan ide dari
00:09:38hal ini adalah ia kembali lagi seperti instruksi utama bagi clod code untuk proyek tertentu tersebut,
00:09:43untuk segala maksud dan tujuan, clod code akan melihat file ini sebelum setiap tugas yang
00:09:50ia laksanakan; jadi jika Anda ingin ia mengingat hal-hal spesifik, apa yang akan Anda lakukan? Anda akan
00:09:54menaruhnya di clod.md; secara teoritis ini skala yang lebih kecil daripada sesuatu seperti RAG, Anda tahu kita
00:10:00tidak memasukkan dokumen lengkap di sini, tetapi hal-hal yang Anda ingin agar clod code
00:10:05selalu ingat dan konvensi yang Anda ingin ia ikuti; jadi untuk yang satu ini kita memiliki bagian tentang saya,
00:10:09kita memiliki rincian struktur sistem file dan bagaimana kita ingin ia beroperasi saat
00:10:14kita memberikan perintah, dan seperti yang saya katakan karena ini dirujuk pada dasarnya di setiap prompt, clod code
00:10:18sangat mahir dalam mengikutinya; jadi ide seperti, "hei aku ingin ia ingat hal-hal spesifik," ini
00:10:22tampaknya tempat yang bagus untuk menaruhnya tetapi kita harus berhati-hati karena kita bisa melakukannya secara berlebihan; saat kita melihat
00:10:28studi seperti yang satu ini tentang mengevaluasi agents.md, dan Anda bisa mengganti agents.md dengan clod.md,
00:10:33mereka menemukan dalam studi tersebut bahwa file-file semacam ini sebenarnya dapat mengurangi efektivitas model
00:10:40bahasa besar secara luas, dan mengapa demikian? Itu karena hal yang membuatnya begitu bagus, fakta
00:10:45bahwa ia disisipkan ke hampir setiap prompt, adalah hal yang juga dapat membuatnya menjadi sangat buruk; apakah kita sebenarnya
00:10:51menyisipkan konteks yang benar? Sudahkah kita menembus kebisingan dan apakah kita benar-benar memberikannya sinyal yang tepat
00:10:57atau apakah kita hanya memasukkan hal-hal yang kita anggap baik? Karena jika itu tidak relevan untuk
00:11:02hampir setiap prompt yang akan dilakukan di proyek Anda, haruskah itu ada di sini di clod.md?
00:11:08Apakah ini cara yang baik untuk membiarkan clod code mengingat banyak hal? Saya berpendapat tidak, tidak juga, dan itu
00:11:15bertentangan dengan apa yang dikatakan banyak orang tentang clod.md dan bagaimana Anda harus menyusunnya berdasarkan studi
00:11:20seperti itu dan berdasarkan pengalaman pribadi; lebih sedikit lebih baik, polusi konteks itu nyata, pembusukan konteks itu nyata,
00:11:26jadi jika ada sesuatu di dalam clod.md dan itu tidak masuk akal untuk, sekali lagi, hampir setiap
00:11:32prompt yang Anda berikan, haruskah itu ada di sana? Jawabannya tidak, tapi kebanyakan orang tidak menyadari itu dan
00:11:37sebaliknya mereka terjebak dalam buku aturan yang membengkak; sebaliknya keterampilan yang harus kita kuasai
00:11:42adalah bagaimana kita menciptakan konteks proyek yang bersinyal tinggi; bagaimana saya memastikan apa yang sebenarnya saya masukkan
00:11:48ke dalam benda ini masuk akal dan seiring dengan itu muncul ide kesadaran pembusukan konteks seperti yang kita bicarakan
00:11:53di level sebelumnya; dan jika Anda menggabungkan semuanya, level dua terasa seperti Anda telah
00:11:57bergerak maju seperti, "hei aku mengambil peran aktif dalam memori, aku punya file clod.md ini," Anda menyadari
00:12:02itu belum cukup, dan saat kita berbicara tentang level tiga dan apa yang bisa kita lakukan untuk maju di sana,
00:12:08kita ingin memikirkan tentang semacam bukan buku aturan statis tetapi sesuatu yang bisa berevolusi dan itu adalah
00:12:14sesuatu yang bisa menyertakan clod.md alih-alih mengandalkan clod.md untuk melakukan segalanya; bagaimana jika kita
00:12:18menggunakan clod.md sebagai semacam file indeks yang mengarahkan clod code ke arah yang benar sebagai gantinya?
00:12:24Jadi apa yang saya maksud tentang clod.md yang bertindak sebagai semacam indeks dan menunjuk ke file lain?
00:12:30Maksud saya adalah arsitektur di dalam basis kode Anda yang tidak hanya memiliki satu file markdown
00:12:37yang mencoba menangani semua masalah memori dalam bentuk clod.md; maksud saya adalah memiliki
00:12:41beberapa file untuk tugas-tugas tertentu; saya rasa contoh yang bagus dari hal ini beraksi adalah semacam apa yang dilakukan GSD,
00:12:47alat orkestrasi Get Shit Done, ia tidak hanya membuat satu file yang mengatakan, "hei ini yang
00:12:53akan kita bangun dan ini persyaratannya dan ini yang telah kita lakukan dan ke mana tujuan kita,"
00:12:56sebaliknya ia membuat banyak file; Anda bisa melihat di sebelah kiri kita memiliki project.md, requirements.md,
00:13:02roadmap, dan state; persyaratan ada agar clod code selalu tahu dan memiliki memori tentang
00:13:08apa yang seharusnya ia bangun; peta jalan merinci apa sebenarnya yang akan kita
00:13:12buat, bukan hanya sekarang tetapi apa yang telah kita lakukan di masa lalu dan di masa depan, dan proyek memberikan
00:13:16memori, memberikan konteks tentang apa yang kita lakukan secara garis besar, apa tujuan utama kita, dan dengan
00:13:22memecah memori dan konteks serta konvensi dalam sistem semacam ini kita melawan ide
00:13:29pembusukan konteks dan ide yang diajukan dalam studi tersebut, yaitu menyisipkan file-file ini ke dalam setiap
00:13:34prompt sepanjang waktu seperti yang kita lakukan di clod.md, itu sebenarnya kontra-intuitif, itu tidak membantu kita mendapatkan
00:13:39output yang lebih baik. Lebih jauh lagi, memecahnya menjadi potongan-potongan ini dan memiliki jalur yang jelas untuk clod
00:13:44code lewati dan berkata seperti, "hei aku ingin mencari tahu di mana informasi ini, oh aku pergi ke clod.md,"
00:13:49"oh clod.md bilang ini lima opsi saya, oke ini yang satu itu, biarkan saya pergi dan mencarinya,"
00:13:54struktur semacam itu adalah apa yang akan Anda lihat 100% di level selanjutnya saat kita membahas
00:13:58Obsidian dan sebenarnya semacam imajinasi ulang kasar dari sistem pemotongan (chunking) dan
00:14:04pencarian kemiripan vektor yang kita lihat di sistem RAG yang sebenarnya, tetapi jelas ini skalanya kecil;
00:14:10di level ini kita berbicara tentang empat file markdown di sini, kita tidak berbicara tentang sistem yang
00:14:14dapat menangani ribuan dan ribuan dokumen; tetapi seperti yang akan sering Anda dengar saya bicarakan,
00:14:20apa artinya bagi Anda? Apakah Anda butuh sistem yang akan kita bahas di level empat,
00:14:26lima, enam, tujuh yang dapat menangani dokumen sebanyak ini? Jawabannya mungkin tidak; dan jadi bagian dari perjalanan
00:14:32RAG ini adalah memahami bukan hanya di mana posisi Anda tetapi seperti ke mana Anda sebenarnya perlu pergi; apakah
00:14:36Anda selalu perlu berada di level tujuh dan tahu cara melakukan sistem RAG agantik di dalam clod code?
00:14:41Mungkin bagus untuk tahu cara melakukannya, tetapi sama bagusnya juga untuk tahu kapan Anda tidak perlu
00:14:46menerapkannya; terkadang apa yang kita lihat di sistem seperti ini sudah cukup bagi banyak orang,
00:14:52jadi sama pentingnya untuk tahu cara melakukannya dan untuk tahu apakah Anda perlu melakukannya, haruskah Anda melakukannya.
00:14:58Saat kita berbicara tentang level tiga dan kita berbicara tentang file state, bagaimana kita tahu kita ada di sini?
00:15:00Nah, kita tahu kita ada di sini saat kita masih benar-benar berada di dalam ekosistem clod code; kita belum
00:15:04mengintegrasikan alat atau aplikasi luar dan sebenarnya kita baru di tahap di mana kita hanya membuat
00:15:09beberapa file markdown untuk membuat sistem pemotongan memori buatan sendiri;
00:15:14tapi ini tetap sangat penting, kita masih menguasai beberapa keterampilan nyata di sini; ide tentang
00:15:18benar-benar menyusun dokumen, memiliki sistem yang memperbarui status di setiap
00:15:23sesi karena ini bisa menjadi masalah dengan RAG juga: bagaimana Anda memastikan semuanya mutakhir?
00:15:28Dan kemungkinan besar Anda juga mulai condong ke lapisan orkestrasi pada titik ini, hal-hal seperti
00:15:33GSD dan kekuatan super yang melakukan hal-hal seperti ini, arsitektur multi-file markdown, atas kemauan mereka sendiri; tapi
00:15:40ada jebakan nyata di sini: apa yang kita buat di proyek ini sangat khusus hanya untuk proyek itu saja, agak
00:15:46kaku untuk kemudian mengambil file markdown tersebut dan memindahkannya ke proyek lain; jadi level
00:15:51empat adalah saat kita memasukkan Obsidian, dan ini adalah alat yang mendapatkan banyak sorotan
00:15:56dan untuk alasan yang bagus; ketika Anda memiliki orang-orang seperti Andrej Karpathy berbicara tentang
00:16:00basis pengetahuan LLM yang telah mereka buat, yang dibangun untuk segala maksud dan tujuan di atas fondasi
00:16:06Obsidian; itu mendapatkan hampir 20 juta penayangan; kita mungkin harus mendengarkan dan melihat bagaimana ini sebenarnya
00:16:11beroperasi; sekarang untuk konteks saya telah melakukan analisis mendalam tentang basis pengetahuan LLM Obsidian Andrej Karpathy
00:16:18ini, saya akan menautkannya di atas; jadi jika Anda ingin fokus pada hal itu, cara membangunnya, pastikan Anda memeriksanya
00:16:22di atas; dan apa yang juga ingin saya sampaikan kepada kebanyakan orang adalah bahwa Obsidian yang akan
00:16:27kita bahas tepat di sini di level empat ini, sejujurnya adalah level yang harus diupayakan oleh kebanyakan orang
00:16:32karena ini sudah cukup bagi kebanyakan orang dalam kebanyakan kasus penggunaan; saat kita berbicara tentang level lima, enam, dan
00:16:37tujuh, kita akan berbicara tentang struktur RAG yang sebenarnya dan sejujurnya itu berlebihan bagi kebanyakan orang; ini
00:16:43berlebihan bagi kebanyakan orang; seperti kita suka membicarakan RAG seolah-olah itu hebat, saya mengerti itu, tapi
00:16:50Obsidian adalah solusi 80% yang dalam kenyataannya seperti solusi 99% bagi kebanyakan orang karena gratis,
00:16:56pada dasarnya tidak ada biaya tambahan, dan itu melakukan tugasnya bagi operator solo; dan saat saya bilang itu melakukan tugasnya
00:17:02bagi operator solo, maksud saya itu menyelesaikan masalah menghubungkan clod code ke banyak
00:17:07dokumen yang berbeda, banyak file markdown yang berbeda, dan mampu mendapatkan informasi yang akurat dan tepat waktu
00:17:13darinya serta memiliki wawasan terhadap dokumen-dokumen tersebut sebagai manusia; karena saat saya mengklik
00:17:19dokumen-dokumen ini, sangat jelas apa yang terjadi di dalamnya dan sangat jelas dokumen apa saja
00:17:24yang terkait dengannya; saat saya mengklik tautan ini saya dibawa ke lebih banyak dokumen, saat saya mengklik tautan ini
00:17:30saya dibawa ke lebih banyak dokumen lagi; jadi bagi saya sebagai manusia, memiliki wawasan ini penting
00:17:36karena sejujurnya wawasan berbasis Obsidian terhadap dokumen tersebut saya berpendapat lebih unggul daripada
00:17:42banyak wawasan yang Anda dapatkan dari sistem RAG ketika kita berbicara tentang ribuan dan ribuan
00:17:47ribuan dokumen yang tertanam dalam sistem seperti graph RAG ini terlihat bagus secara visual
00:17:52terlihat sangat memukau, tapi apakah Anda benar-benar tahu apa yang terjadi di dalamnya? Mungkin saja,
00:17:58jujur saja Anda hanya mengandalkan jawaban yang muncul dan tautannya, tapi agak sulit
00:18:03untuk menelusuri embedding-nya. Intinya adalah Anda harus memberi perhatian khusus
00:18:08pada Obsidian dan Claude Code karena saat kita bicara soal perjalanan dari RAG, saya selalu menyarankan
00:18:13kepada semua orang, termasuk klien, untuk mulai dengan Obsidian saja dan lihat seberapa jauh kita bisa mengembangkannya
00:18:20dan akhirnya, jika kita menemui jalan buntu, Anda selalu bisa beralih ke sistem RAG yang lebih kuat. Jadi mengapa tidak
00:18:26mencoba opsi yang sederhana? Jika berhasil, bagus, gratis, tidak memakan biaya, dibandingkan jika kita langsung
00:18:31mencoba sistem RAG yang bisa agak sulit untuk diproduksi tergantung pada apa yang ingin Anda
00:18:35lakukan. Selalu mulai dengan hal-hal sederhana, tidak pernah terlalu sulit untuk beralih ke sesuatu yang lebih
00:18:40rumit. Jadi apa yang sebenarnya kita bicarakan di level empat? Kita bicara tentang mengambil
00:18:45struktur yang mulai kita bangun di level 3, Anda tahu, dengan file indeks yang menunjuk ke berbagai
00:18:50file markdown dan meningkatkannya, lalu membawa alat luar yaitu Obsidian untuk memudahkan
00:18:56Anda sebagai manusia untuk melihat koneksi ini. Dan bentuk ideal dari versi ini
00:19:00adalah apa yang dipaparkan Andre Karpathy tentang membangun basis pengetahuan LLM di atas Obsidian
00:19:05dan ditenagai oleh Claude Code. Dan tampilannya adalah struktur seperti ini: saat Anda menggunakan Obsidian
00:19:11dan mengunduhnya, itu sepenuhnya gratis, sekali lagi lihat video yang saya posting sebelumnya, Anda menetapkan
00:19:16file tertentu sebagai "vault". Anggap vault sebagai sistem RAG, semacam sistem RAG kuasi
00:19:23yang telah Anda buat, dan di dalam vault tersebut kita kemudian merancang arsitekturnya, menyusunnya hanya dengan
00:19:30file. Jadi kita punya file utama yang disebut vault, dan di dalam vault itu kita membuat beberapa
00:19:36subfolder. Dalam kasus Andre Karpathy, dia bicara tentang tiga subfolder berbeda. Kenyataannya,
00:19:41folder tersebut bisa apa saja, hanya perlu sesuai dengan tema yang akan kita bahas. Di salah satu
00:19:47folder, kita punya data mentah. Ini adalah semua yang kita masukkan dan ingin kita susun agar
00:19:52Claude Code bisa mereferensikannya nanti. Bayangkan Anda menyuruh Claude Code melakukan analisis kompetitif terhadap
00:19:5850 kompetitor Anda dan dia menarik 50 situs untuk masing-masing kompetitor. Kita bicara tentang sejumlah besar
00:20:03informasi, mungkin sekitar 2500 hal berbeda. Semuanya akan dimasukkan ke dalam folder mentah (raw).
00:20:08Ini seperti area persiapan untuk data. Kemudian kita punya folder wiki. Folder wiki adalah tempat
00:20:14data terstruktur berada. Kita menyuruh Claude Code mengambil data mentah ini dan menyusunnya menjadi
00:20:20artikel tipe Wikipedia yang berbeda di dalam folder wiki. Setiap artikel mendapat foldernya sendiri.
00:20:28Idenya adalah saat Anda menanyakan informasi kepada Claude Code tentang, katakanlah kita menyuruhnya
00:20:33mencari hal-hal tentang agen AI dan saya bilang, "Hei Claude Code, beri tahu saya tentang agen AI," dengan cara yang sama
00:20:38seperti Anda menanyakan sistem RAG. Nah, Claude Code akan pergi ke vault, dari vault dia akan pergi
00:20:45ke wiki. Wiki tersebut memiliki file markdown indeks utama. Ingatlah apa yang tadi kita
00:20:50bicarakan tentang clod.md sebelumnya, kan? Anda lihat bagaimana tema-tema ini bertransisi
00:20:56melalui level yang berbeda. Dia melihat indeks utama, dan indeks utama memberitahunya apa saja
00:21:00yang ada di sistem RAG Obsidian. "Oh, agen AI ada, keren." Tebak apa yang terjadi selanjutnya,
00:21:08dia juga punya file indeks yang membahas artikel-artikel individu yang ada. Apa yang ingin saya sampaikan?
00:21:14Saya katakan ada hierarki yang jelas untuk direferensikan Claude Code saat ingin menemukan informasi tentang
00:21:21file: vault, wiki, indeks, artikel, dsb. Karena pencarian informasinya sangat jelas,
00:21:31dan sangat jelas cara menemukan informasi lalu mengubahnya menjadi wiki, kita bisa membuat sistem yang memiliki
00:21:37banyak dokumen tanpa RAG. Ratusan, ribuan, jika Anda melakukannya dengan benar, karena jika sistemnya jelas,
00:21:44"Hei, saya periksa vault dan indeksnya," dan itu punya garis pemisah yang jelas tentang lokasi segalanya, maka
00:21:50tidak terlalu sulit bagi Claude Code untuk mencari tahu di mana menemukan sesuatu. Jadi Anda bisa menggunakan
00:21:54struktur non-RAG untuk ribuan dokumen, padahal hal itu sangat sulit dilakukan di masa lalu.
00:21:58Itu karena kebanyakan orang tidak menyusun apa pun dengan struktur apa pun; mereka hanya punya semiliar
00:22:02dokumen yang tergeletak dalam satu folder. Itu setara dengan memiliki 10 juta file yang berserakan di lantai pabrik.
00:22:08Maksud saya, apakah Claude Code akan menemukannya? Tidak. Anda sebenarnya hanya butuh lemari arsip.
00:22:13Claude Code sebenarnya cukup pintar dan Anda bisa melihat arsitektur itu beraksi di sini. Saat ini kita
00:22:17melihat file clod.md yang ada di vault Obsidian, dan apa isinya? Isinya menguraikan
00:22:24struktur vault, sistem wiki, struktur keseluruhan subfolder, dan cara untuk
00:22:30menjalankannya. Jadi sekali lagi kita menggunakan clod.md sebagai file tipe konvensi di sini. Di sebelah kiri,
00:22:36Anda bisa melihat folder wiki. Di dalam folder wiki ada indeks utama dan di sana terdaftar apa saja isi di
00:22:43dalamnya. Dalam kasus ini, hanya ada satu artikel tentang agen yang dikelola Claude. Di dalam folder itu kita lihat
00:22:49agen yang dikelola Claude, ia punya folder wiki sendiri yang menguraikan artikel di dalamnya
00:22:55sampai Anda mencapai artikel yang sebenarnya. Jadi langkah-langkah yang perlu diambil sangat jelas. Maka saat saya menyuruh Claude Code,
00:23:01"Bicaralah padaku tentang agen terkelola," kita punya wiki tentang itu, sangat mudah baginya untuk mencari melalui
00:23:06alat grep bawaannya. Dia menautkan saya ke file markdown asli dan kemudian menguraikan semua
00:23:12yang terjadi. Sekarang pertanyaan di level empat benar-benar menjadi masalah skala. Berapa banyak dokumen
00:23:16yang bisa kita masukkan di mana sistem semacam ini terus berfungsi? Apakah ada titik di mana sistem
00:23:22Andre Karpathy mulai runtuh? Di mana, "Hei, saya paham jalurnya sangat jelas untuk diikuti Claude Code,
00:23:26dia pergi ke indeks, dan seterusnya," apakah itu bisa bertahan pada
00:23:312.000 dokumen? 2.500? 3.000? Apakah ada angka yang pasti? Jawabannya adalah kita tidak benar-benar tahu.
00:23:37Bisa jadi angkanya lebih kecil karena semua dokumen Anda juga berbeda. Dan soal menemui hambatan, itu tidak
00:23:43sesederhana, "Claude Code memberikan jawaban yang salah." Dia punya terlalu banyak file di dalam
00:23:47sistem Obsidian. Berapa biaya token yang harus Anda keluarkan sekarang setelah kita menambahkan begitu banyak file dan seberapa
00:23:52cepat kinerjanya? Karena RAG sebenarnya bisa jauh lebih cepat dan murah dalam situasi tertentu.
00:23:59Yang kita lihat di sini adalah perbandingan antara LLM tekstual (batang yang besar) dan
00:24:06RAG tekstual dalam hal jumlah token yang dibutuhkan untuk mendapatkan jawaban yang benar dan jumlah waktu yang
00:24:11dibutuhkan untuk mendapatkan jawaban itu. Apa yang kita lihat di sini? Kita lihat bahwa RAG tekstual versus LLM tekstual
00:24:18memiliki perbedaan besar, mencapai 1200 kali lipat. Saya katakan RAG 1200 kali lebih murah dan 1200
00:24:25kali lebih cepat daripada LLM tekstual dalam studi ini. Sebagai konteks, ini dilakukan tahun 2025, bukan dengan
00:24:33Claude Code. Model-model ini telah berubah secara signifikan sejak saat itu. Ini hanyalah LLM murni,
00:24:37bukan asisten pengkodean, dsb. Namun, kita bicara tentang perbedaan 1200x. Jadi saat kita mengevaluasi,
00:24:48"Hei, apakah Obsidian yang harus saya pakai ataukah saya harus menggunakan sistem RAG?" itu tidak sesederhana
00:24:54apakah ia memberikan jawaban yang benar atau tidak. Karena Anda bisa saja berada dalam skenario
00:24:59di mana Anda mendapatkan jawaban yang benar dengan Obsidian, namun jika Anda menggunakan RAG, biayanya seribu kali lebih murah
00:25:04dan lebih cepat. Jadi ada garis yang sangat kabur antara kapan Obsidian sudah cukup baik dan
00:25:10arsitektur file markdown semacam ini sudah cukup memadai, dibandingkan kapan kita perlu menggunakan RAG.
00:25:15Tidak ada jawaban yang pasti. Saya tidak punya jawaban pasti untuk Anda. Jawabannya adalah Anda harus bereksperimen
00:25:18dan Anda perlu mencoba keduanya dan melihat mana yang berhasil. Karena data ini sejujurnya sudah usang, benar-benar tahun 2025,
00:25:25model lama. Perbedaan antara RAG dan LLM tekstual mungkin bukan 1200 kali lagi, tapi seberapa jauh kesenjangan itu menyusut?
00:25:32Karena itu adalah kesenjangan yang gila, bukan cuma 10x tapi 1200x. Jadi ada banyak hal yang harus Anda ketahui dan
00:25:39sekali lagi, Anda tidak akan tahu jawabannya di awal. Anda tidak akan tahu. Tontonlah video apa pun yang Anda mau,
00:25:45tidak ada yang akan memberi tahu di mana garis batasnya. Anda benar-benar hanya perlu bereksperimen
00:25:49dan melihat apa yang berhasil untuk Anda seiring bertambahnya jumlah dokumen yang Anda minta Claude Code
00:25:54untuk menjawab pertanyaannya. Jadi, mari kita lanjut ke level lima, di mana kita akhirnya
00:25:59mulai bicara tentang sistem RAG yang sebenarnya dan membahas beberapa dasar RAG seperti embedding,
00:26:04database vektor, dan bagaimana data sebenarnya mengalir melalui sistem saat menjadi bagian dari
00:26:10basis pengetahuan RAG kita. Mari kita mulai dengan membahas RAG naif (naive RAG), tipe RAG yang paling dasar
00:26:16tapi memberikan fondasi untuk hal lain yang kita lakukan. Anda bisa menganggap sistem RAG
00:26:21terbagi menjadi tiga bagian. Di sisi kiri kita punya tahap embedding, kita kemudian
00:26:27punya database vektor, dan kemudian kita punya pengambilan (retrieval) yang sebenarnya dilakukan dengan model bahasa
00:26:33besar. Jadi satu, dua, dan tiga. Dan untuk mengilustrasikan model ini dengan baik, mari kita mulai dengan perjalanan
00:26:40sebuah dokumen yang akan menjadi bagian dari basis pengetahuan kita. Ingat, dalam sistem RAG besar kita bisa bicara
00:26:45tentang ribuan dokumen dan setiap dokumen bisa berisi ribuan halaman. Tapi dalam
00:26:50contoh ini, kita punya dokumen satu halaman yang sedang kita bicarakan. Nah, jika kita ingin menambahkan dokumen ini
00:26:56ke database kita, cara kerjanya adalah dokumen tersebut tidak akan dimasukkan secara utuh. Sebaliknya,
00:27:03kita akan mengambil dokumen ini dan memotong-motongnya menjadi beberapa bagian (chunk). Jadi satu halaman ini
00:27:08pada dasarnya menjadi tiga potongan berbeda. Ketiga potongan ini kemudian dikirim ke model embedding,
00:27:15dan tugas model embedding adalah mengambil ketiga potongan ini dan mengubahnya menjadi vektor
00:27:21di dalam database vektor. Nah, database vektor hanyalah variasi yang berbeda dari database standar Anda.
00:27:27Saat kita bicara tentang database standar, bayangkan sesuatu seperti dokumen Excel, kan? Anda punya
00:27:32kolom dan baris. Nah, dalam database vektor, isinya bukan kolom dan baris dua dimensi, melainkan
00:27:37ratusan bahkan ribuan dimensi. Tapi untuk tujuan hari ini, bayangkan saja sebuah
00:27:43grafik tiga dimensi seperti yang Anda lihat di sini. Dan vektor hanyalah titik-titik di grafik itu, dan setiap
00:27:50titik diwakili oleh serangkaian angka. Jadi Anda bisa lihat di sini kita punya pisang, dan pisang
00:27:57diwakili oleh 0.52, 5.12, lalu 9.31. Anda bisa melihatnya di atas sini. Itu berlanjut hingga ratusan angka.
00:28:06Nah, di mana setiap vektor ditempatkan dalam grafik multi-dimensi raksasa ini tergantung pada makna
00:28:13semantiknya—apa arti sebenarnya dari kata-kata tersebut. Jadi Anda bisa lihat di sebelah sini, ini seperti bagian
00:28:19buah-buahan: ada pisang, apel, dan pir. Di sebelah sana kita punya kapal laut dan perahu.
00:28:24Jadi kembali ke dokumen kita, mari kita bayangkan bahwa dokumen ini adalah tentang kapal perang Perang Dunia II.
00:28:31Maka setiap potongan ini akan diubah menjadi serangkaian angka, dan serangkaian angka tersebut
00:28:37akan direpresentasikan sebagai titik di grafik ini. Menurut Anda, di mana titik itu akan berada? Yah, kemungkinan
00:28:42besar di sekitar area ini, kan? Jadi itu akan menjadi satu, dua, dan tiga. Begitulah cara dokumen ditempatkan. Setiap
00:28:49dokumen akan dipotong, setiap potongan masuk ke model embedding, dan model embedding
00:28:54memasukkannya ke database vektor. Ulangi, ulangi, ulangi untuk setiap dokumen. Dan pada akhirnya,
00:28:58setelah kita melakukannya beberapa ribu kali, kita mendapatkan database vektor yang mewakili grafik pengetahuan
00:29:04kita, basis pengetahuan kita. Dan itu membawa kita ke langkah ketiga, yaitu bagian pengambilan (retrieval).
00:29:09Jadi di mana peran Anda dalam hal ini? Biasanya, mari kita gambarkan Anda... kita beri Anda
00:29:16warna yang berbeda, Anda jadi warna merah muda. Jadi ini adalah Anda, oke? Anda biasanya hanya berbicara dengan
00:29:23Claude Code dan Anda mengajukan pertanyaan kepada Claude Code tentang kapal perang Perang Dunia II. Nah, dalam pengaturan
00:29:29standar non-RAG, apa yang akan terjadi? Model bahasa besar Opus 4.6 akan melihat
00:29:34data pelatihannya dan kemudian memberikan jawaban kepada Anda berdasarkan data pelatihan tersebut,
00:29:39informasi tentang kapal perang Perang Dunia II. Tetapi dengan sistem RAG, ia akan melakukan lebih banyak hal. Ia akan
00:29:44mengambil vektor yang sesuai. Ia akan menggunakan vektor-vektor tersebut untuk memperkaya (augment) jawaban yang ia hasilkan
00:29:51untuk Anda. Itulah "Retrieval Augmented Generation". Itulah kekuatan RAG. Ia memungkinkan model bahasa besar
00:29:56kita untuk menarik informasi yang bukan merupakan bagian dari data pelatihannya untuk memperkaya jawabannya. Dalam
00:30:02contoh ini, kapal perang Perang Dunia II, ya saya paham model bahasa besar sudah mengetahuinya, tapi
00:30:06gantilah ini dengan data perusahaan apa pun yang bersifat rahasia dan tidak tersedia di web, dan lakukan itu
00:30:15dalam skala besar. Itulah nilai jual RAG. Nah, dalam contoh kita, saat kita meminta Claude Code untuk memberikan pertanyaan tentang
00:30:21informasi mengenai kapal perang Perang Dunia II dan itu dalam pengaturan RAG, apa yang akan ia lakukan adalah ia akan
00:30:25mengambil pertanyaan kita dan mengubah pertanyaan kita menjadi serangkaian angka yang mirip dengan
00:30:32vektor-vektor di sebelah sini. Ia kemudian akan melihat berapa angka untuk pertanyaan kita dan angka-angka
00:30:39dari vektor-vektor yang ada, dan ia akan melihat mana dari vektor-vektor ini yang paling cocok dengan vektor pertanyaan kita,
00:30:46kan? Seberapa mirip vektor-vektor tersebut dengan pertanyaannya, kira-kira begitu. Lalu ia akan menarik sejumlah
00:30:51vektor, entah itu satu, dua, tiga, empat, lima, sepuluh, atau dua puluh. Dan ia akan menarik
00:30:56vektor-vektor tersebut beserta informasinya ke dalam model bahasa besar. Jadi sekarang model bahasa besar memiliki
00:31:02jawaban dari data pelatihannya ditambah dengan, katakanlah, 10 vektor informasi, kan? Itu tadi adalah bagian pengambilannya,
00:31:09dan kemudian ia memperkaya dan menghasilkan jawaban dengan informasi tambahan tersebut. Dan begitulah cara RAG
00:31:13bekerja. Begitulah cara RAG naif bekerja. Namun ini tidak terlalu efektif karena sejumlah alasan. Struktur
00:31:19yang sangat mendasar ini mulai runtuh di awal saat kita mulai berpikir tentang, "Oke, bagaimana
00:31:25cara kita memotong-motong dokumen ini? Apakah acak? Apakah hanya berdasarkan jumlah token murni? Apakah kita punya
00:31:31jumlah tumpang tindih tertentu? Apakah dokumen-dokumen itu sendiri diatur sedemikian rupa sehingga masuk akal
00:31:36untuk dipotong-potong?" Karena bagaimana jika, Anda tahu, potongan nomor tiga merujuk pada sesuatu di potongan
00:31:42nomor satu, lalu dalam situasi vektor kita, saat kita menarik potongan-potongan itu, bagaimana jika ia tidak mendapatkan yang benar?
00:31:47Bagaimana jika ia tidak mendapatkan potongan lain yang diperlukan sebagai konteks? Agar apa yang dikatakan di
00:31:53nomor tiga bisa masuk akal. Maksud saya, sering kali seluruh dokumen itu sendiri diperlukan untuk menjawab
00:31:59pertanyaan tentang dokumen tersebut. Jadi ide untuk mendapatkan jawaban sepotong-sepotong ini tidak benar-benar
00:32:05berhasil dalam praktiknya, padahal begitulah cara RAG diatur untuk waktu yang sangat lama. Masalah lain yang bisa
00:32:10muncul adalah hal-hal seperti: bagaimana jika saya punya pertanyaan tentang hubungan antara berbagai vektor?
00:32:17Karena saat ini saya hanya menarik vektor secara terpisah. Tapi bagaimana jika saya ingin tahu bagaimana hubungan perahu dengan
00:32:22pisang? Kedengarannya acak, tapi bagaimana jika saya mau tahu? Anda tahu, pendekatan database vektor RAG naif standar
00:32:31seperti ini membuat segala sesuatunya terisolasi. Sulit untuk menghubungkan informasi dan banyak hal bergantung
00:32:36pada seberapa baik dokumen-dokumen asli tersebut disusun. Apakah mereka disusun dengan cara yang
00:32:41masuk akal untuk proses RAG? Selama bertahun-tahun, kita telah menemukan beberapa cara untuk meredakan masalah ini,
00:32:46seperti re-ranker atau sistem pemeringkatan yang meninjau semua vektor yang kita ambil dan pada dasarnya
00:32:51melakukan peninjauan ulang dengan model bahasa besar untuk mengurutkannya berdasarkan relevansinya. Tapi
00:32:56secara umum sistem RAG naif ini sudah mulai ditinggalkan. Namun, tetap penting untuk
00:33:03memahami cara kerjanya di tingkat dasar agar ini bisa menginformasikan keputusan Anda jika Anda memilih
00:33:07pendekatan RAG yang lebih kuat. Karena jika Anda tidak mengerti cara kerja pemotongan (chunking) atau embedding,
00:33:13bagaimana Anda bisa membuat keputusan tentang bagaimana Anda harus menyusun dokumen Anda? Saat kita bicara tentang
00:33:17sesuatu seperti graphRAG atau kita bicara tentang sistem embedding yang lebih rumit seperti
00:33:22yang terbaru dari Google yang sebenarnya bisa memproses bukan cuma teks tapi juga video. Dan jika Anda tidak mengerti
00:33:27fondasi semacam ini, sulit bagi Anda untuk benar-benar memahami jebakan ini. Dan jebakannya adalah
00:33:31bahwa kita sebenarnya cuma membuat mesin pencari yang buruk. Karena dengan sistem RAG naif ini, yang kita
00:33:36lakukan hanyalah mengambil potongan-potongan dan kita tidak benar-benar bisa memahami hubungan di antara mereka, lalu apa bedanya
00:33:42dengan sekadar memiliki sistem pencarian "control F" yang terlalu rumit? Jawabannya, sebenarnya tidak
00:33:48banyak perbedaan. Itulah mengapa dalam struktur RAG yang sederhana dan agak usang ini, yang sebenarnya masih
00:33:54banyak ditemukan di mana-mana... Jika Anda melihat seseorang yang bilang, "Oh, ini sistem RAG Pinecone saya," atau "Ini sistem
00:33:58RAG Supabase saya," dan mereka tidak menyebutkan apa pun tentang graphRAG atau mereka tidak menyebutkan apa pun
00:34:03seperti, "Hei, ini cara kami menggunakan sistem re-ranker yang canggih," maka hasilnya akan buruk,
00:34:07efektivitasnya mungkin cuma sekitar 25% dari waktu Anda mendapatkan jawaban yang benar. Anda bahkan hampir lebih baik menebak.
00:34:12Jadi jika Anda tidak tahu hal itu sejak awal, Anda pasti bisa tertipu atau bingung, atau dalam beberapa kasus,
00:34:18pada dasarnya tertipu untuk membeli sistem RAG yang tidak masuk akal. Jadi level lima bukan tentang menerapkan
00:34:23sistem RAG naif ini; ini tentang memahami cara kerjanya sehingga saat tiba waktunya untuk menerapkan
00:34:28sesuatu yang lebih canggih, Anda benar-benar mengerti apa yang sedang terjadi. Karena
00:34:34penjelasan lima menit tentang RAG tadi sayangnya bukanlah sesuatu yang dipahami kebanyakan orang saat mereka bilang,
00:34:38"Saya butuh sistem RAG." Benarkah? Karena Anda juga harus bertanya pada diri sendiri, pertanyaan macam apa yang sebenarnya
00:34:43Anda ajukan tentang sistem Anda? Jika Anda hanya menanyakan hal-hal yang, pada dasarnya memperlakukan basis pengetahuan Anda
00:34:48sebagai buku peraturan raksasa dan Anda hanya butuh hal-hal spesifik dari sistem pengetahuan itu untuk
00:34:54dimunculkan, maka Obsidian mungkin sudah cukup, atau Anda bahkan mungkin bisa menggunakan sistem RAG naif.
00:34:59Tapi jika kita perlu tahu tentang hubungan, jika kita perlu tahu bagaimana X berinteraksi dengan Y dan
00:35:02mereka ada di dua dokumen terpisah yang bahkan tidak pernah saling menyebutkan satu sama lain, dan itu bukan sesuatu
00:35:09yang bisa saya masukkan ke dalam konteks secara langsung karena saya punya ribuan dokumen seperti itu, nah
00:35:13di situlah Anda akan membutuhkan RAG, dan di situlah Anda akan membutuhkan sesuatu yang lebih canggih
00:35:19daripada RAG vektor dasar. Di situlah kita harus mulai bicara tentang graphRAG. Jadi saat kita bicara tentang level
00:35:23enam dari Claude Code dan RAG, kita bicara tentang graphRAG. Dan menurut pendapat saya,
00:35:29jika Anda akan menggunakan RAG, ini adalah tingkat infrastruktur terendah yang perlu Anda buat.
00:35:34Ini menggunakan LightRAG yang merupakan alat sumber terbuka sepenuhnya. Saya akan menaruh tautan di atas di mana saya
00:35:39menguraikan dengan tepat cara menggunakan dan membangunnya. Tapi ide dari graphRAG cukup jelas: idenya
00:35:44adalah bahwa semuanya terhubung. Ini bukan database vektor dengan sekumpulan vektor yang terisolasi.
00:35:50Ini adalah sekumpulan hal yang terhubung satu sama lain, kan? Saya klik dokumen ini, saya bisa lihat di sebelah sini
00:35:55di sisi kanan—dan saya akan pindahkan ini—deskripsi dari vektornya, namanya, tipenya,
00:36:00file-nya, potongan (chunk)-nya, dan yang lebih penting, hubungan-hubungan yang berbeda. Dan pendekatan berbasis
00:36:05hubungan ini menghasilkan hasil yang lebih efektif. Berikut adalah grafik dari GitHub LightRAG. Grafik ini
00:36:10berusia sekitar enam sampai delapan bulan, dan juga perlu dicatat bahwa LightRAG adalah sistem graphRAG paling ringan
00:36:15di luar sana yang saya tahu. Ada beberapa versi yang sangat kuat, termasuk GraphRAG itu sendiri dari
00:36:23Microsoft; itu secara harfiah disebut GraphRAG. Tapi saat kita membandingkan RAG naif dengan LightRAG,
00:36:30di semua lini kita mendapatkan lonjakan yang sering kali lebih dari 100 persen, kan? 31,6 berbanding 68,4;
00:36:3524 berbanding 76; 24 berbanding 75, dan seterusnya. Meskipun begitu, menurut pihak LightRAG,
00:36:4324 berbanding 75 dan seterusnya, dan karena itu menurut Light RAG hal itu
00:36:49sebenarnya mampu bersaing dan mengalahkan GraphRAG itu sendiri, tapi hei, ini angka dari Light RAG jadi
00:36:54terimalah dengan skeptis. Sekarang, saat kita melihat sistem basis pengetahuan grafik ini,
00:36:58pikiran Anda mungkin langsung tertuju pada Obsidian karena tampilannya sangat mirip,
00:37:04namun apa yang kita lihat di Obsidian jauh lebih dasar daripada apa yang terjadi di dalam Light RAG
00:37:10atau sistem GraphRAG mana pun karena rangkaian koneksi yang kita lihat di sini semuanya manual
00:37:16dan agak sembarangan; itu terhubung hanya karena kita mengatur dokumen terkait atau Claude Code
00:37:22mengatur dokumen terkait saat membuat dokumen ini, misalnya hanya menambahkan beberapa kurung,
00:37:27bum, dokumen itu terhubung. Jadi secara teori saya bisa menghubungkan banyak dokumen acak
00:37:30yang kenyataannya tidak ada hubungannya satu sama lain. Karena Claude Code tidak bodoh,
00:37:35ia tidak akan melakukannya, tapi itu jauh berbeda dengan apa yang terjadi di sini, di mana ini
00:37:41melalui sistem embedding yang sebenarnya; ia melihat konten aslinya, menetapkan hubungan,
00:37:46mengirim entitas; ada jauh lebih banyak pekerjaan yang dilakukan di sini di dalam Light RAG
00:37:52dalam hal mendefinisikan hubungan dibandingkan Obsidian. Sekarang, apakah perbedaan itu
00:38:02benar-benar setara dengan kesenjangan performa yang besar pada tingkat rendah? Mungkin pada skala besar,
00:38:07sekali lagi, kita berada di area abu-abu, tergantung pada skala Anda dan apa yang kita bicarakan,
00:38:13dan tidak ada yang bisa menjawab pertanyaan itu kecuali Anda dan pengalaman pribadi. Namun pahamilah,
00:38:20dua hal ini tidak sama. Kita tidak sama, kawan. Dua sistem yang sama sekali berbeda,
00:38:26satu sangat canggih, satu cukup dasar. Pahami itu, dan untuk merangkum Level 6 di GraphRAG,
00:38:31kita benar-benar sampai di sini ketika kita memutuskan bahwa sesuatu seperti Obsidian tidak berfungsi,
00:38:36kita tidak bisa menggunakan RAG standar karena tidak memadai dan kita butuh sesuatu yang bisa mengekstrak entitas
00:38:43serta hubungan dan benar-benar memanfaatkan desain sistem kueri hibrida vektor plus grafik.
00:38:48Namun ada beberapa jebakan, ada beberapa hambatan serius bahkan di sini pada Level 6
00:38:55saat kita berbicara tentang Light RAG. Ini hanya teks. Bagaimana jika saya punya PDF yang bisa dipindai?
00:39:01Bagaimana jika saya punya video? Bagaimana jika saya punya gambar? Kita tidak hidup di dunia di mana semua dokumen
00:39:06hanya berupa Google Docs, lalu apa yang kita lakukan dalam kasus-kasus tersebut? Jadi, pengambilan multimodal
00:39:11adalah hal yang besar, dan selain itu, bagaimana jika kita membawa kualitas agenik ke sistem ini?
00:39:17Memberinya sedikit lebih banyak kekuatan AI, semacam dorongan di departemen itu? Nah, jika kita
00:39:24berbicara tentang hal-hal multimodal, maka kita akhirnya bisa beralih ke garis depan RAG saat ini,
00:39:31per April 2026 itulah yang menjadi inti dari Level 7. Sekarang, saat kita berbicara tentang Level 7
00:39:36dalam Agentic RAG, hal besar yang ingin kita fokuskan di sini adalah hal-hal yang berkaitan dengan
00:39:44ingesti multimodal. Kami sudah membuat video tentang hal ini, hal-hal seperti "RAG Anything"
00:39:49yang memungkinkan kita mengimpor gambar dan dokumen non-teks, sekali lagi pikirkan PDF yang bisa dipindai,
00:39:56ke dalam struktur seperti grafik pengetahuan Light RAG yang Anda lihat di sini. Kita juga punya rilis baru
00:40:01seperti Gemini Embedding 2 yang baru saja keluar di bulan Maret, yang memungkinkan kita untuk benar-benar
00:40:06memasukkan video ke dalam database vektor kita, video itu sendiri, dan sejujurnya ke sinilah arahnya.
00:40:10Tidak cukup hanya melakukan dokumen teks. Berapa banyak informasi, berapa banyak pengetahuan
00:40:16yang terjebak di internet terutama di tempat-tempat seperti YouTube yang murni berupa video?
00:40:20Dan kita menginginkan lebih dari sekadar transkrip. Sebuah transkrip tidaklah cukup. Jadi masalah multimodal
00:40:25ini nyata, dan sekali lagi ini adalah hal-hal yang baru keluar beberapa minggu yang lalu. Dan Level 7 juga
00:40:30merupakan tempat di mana kita harus mulai memperhatikan arsitektur dan alur kerja kita terkait data
00:40:35yang masuk dan keluar dari sistem RAG kita. Tidak cukup hanya memasukkan data di sini,
00:40:40ini bagus, kita punya semua koneksi ini, tapi bagaimana datanya sampai di sana? Bagaimana datanya sampai
00:40:46ke sana dalam konteks sebuah tim? Bagaimana data keluar dari sana? Bagaimana jika beberapa informasi
00:40:50di sini telah berubah dalam dokumen tertentu? Apa yang terjadi jika seseorang mengeditnya? Bagaimana cara
00:40:54memperbaruinya? Bagaimana jika kita menambahkan duplikat? Siapa yang sebenarnya bisa memasukkan hal-hal ini?
00:41:01Dalam hal tingkat produksi, ini semua adalah pertanyaan yang perlu mulai Anda tanyakan pada diri sendiri.
00:41:06Jadi, saat kita melihat sistem Agentic RAG seperti yang satu ini dari n8n, Anda bisa melihat
00:41:11sebagian besar infrastruktur, semua yang digariskan di sini adalah tentang ingesti data dan sinkronisasi data.
00:41:17Hanya ada sebagian kecil yang berkaitan dengan RAG, yaitu tepat di sana, karena kita butuh sistem
00:41:21yang membersihkan data, yang mampu melihat, "Oke, kita baru saja memasukkan dokumen ini,
00:41:27ternyata ini adalah versi 2 dari versi 1, bisakah kita sekarang kembali dan membersihkan data itu?"
00:41:31Inilah contoh pipa ingesti data di mana dokumen tidak langsung dimasukkan ke dalam sistem,
00:41:37atau di Light RAG kita malah menaruhnya di dalam sesuatu seperti Google Drive dan dari sana
00:41:42itu dimasukkan ke dalam sistem GraphRAG dan dicatat. Hal-hal semacam inilah yang sebenarnya akan
00:41:49menentukan keberhasilan atau kegagalan sistem RAG Anda saat Anda menggunakannya secara nyata.
00:41:54Dan saat kita berbicara tentang Agentic RAG, Anda bisa lihat di sini—dan saya tahu ini agak buram—
00:41:58tapi jika kita memiliki agen AI yang menjalankan seluruh program ini, jadi Anda menyiapkannya,
00:42:03bayangkan semacam chatbot untuk tim Anda. Apakah ia selalu perlu mengakses database ini?
00:42:08Jawabannya mungkin tidak. Kemungkinan besar dalam pengaturan tim atau bisnis, Anda akan memiliki
00:42:15informasi yang ada di database seperti ini, seperti teks, tapi Anda mungkin juga memiliki kumpulan
00:42:20database lain seperti database Postgres standar dengan banyak informasi yang ingin Anda kueri
00:42:23dengan SQL juga. Jadi saat kita berbicara tentang sistem Agentic RAG, kita butuh sesuatu yang memiliki itu semua,
00:42:30kemampuan untuk memutuskan secara cerdas, "Oh, apakah saya akan mengakses database GraphRAG
00:42:34yang direpresentasikan di sini atau saya hanya akan melakukan kueri SQL di Postgres?"
00:42:39Hal-hal ini bisa menjadi rumit, bukan? Dan semua ini tergantung pada kasus penggunaan, itulah mengapa
00:42:46terkadang sulit untuk membuat video seperti ini dan mencoba mencakup setiap kemungkinan kasus.
00:42:50Poin di Level 7 bukanlah bahwa ada sistem super RAG yang belum pernah Anda dengar,
00:42:55melainkan bahwa detailnya sangat penting di sini, dan itu sebagian besar tentang bagian ingesti data
00:43:01dan menjaganya tetap mutakhir, tapi juga tentang bagaimana Anda benar-benar mengakses hal ini.
00:43:07Mudah dilakukan dalam demo di sini, seperti, "Oh, kita tinggal pergi ke Light RAG dan saya buka bagian
00:43:14retrieval dan saya ajukan pertanyaan." Skenarionya berbeda saat kita membicarakannya dengan tim
00:43:19di mana setiap orang mendekatinya dari sudut pandang yang berbeda, dan Anda mungkin tidak ingin
00:43:26semua orang memiliki akses untuk mengunggahnya ke Light RAG itu sendiri di aplikasi web.
00:43:31Meskipun demikian, bagi operator solo yang mencoba membuat sistem RAG yang canggih yang mampu melakukan
00:43:37hal-hal multimodal, saya menyarankan kombinasi RAG Anything plus Light RAG.
00:43:42Saya sudah membuat video tentang itu, dan jika saya belum menautkannya, saya akan menautkannya di atas.
00:43:45Saya menyarankan itu karena beberapa alasan; satu, ini sumber terbuka dan ringan,
00:43:50jadi Anda tidak menghabiskan banyak uang atau waktu untuk menjalankan sesuatu seperti ini
00:43:56hanya untuk memastikan apakah ini benar-benar masuk akal untuk kasus penggunaan Anda.
00:44:02Sekali lagi, yang kita inginkan adalah kita tidak ingin terjebak dalam sistem yang tidak ada jalan keluarnya
00:44:06dan kita sudah menghabiskan banyak uang untuk sampai ke sana, itulah sebabnya saya sangat menyukai Obsidian
00:44:12dan saya selalu merekomendasikan hal-hal seperti Light RAG dan RAG Anything karena hei, jika Anda mencobanya
00:44:16dan tidak berhasil atau tidak masuk akal bagi Anda, ya sudah, Anda hanya menyia-nyiakan beberapa jam,
00:44:20tidak seperti Anda menghabiskan banyak uang untuk GraphRAG dari Microsoft yang sama sekali tidak murah.
00:44:25Jadi, kapan Anda tahu bahwa Anda berada di Level 7? Benar-benar saat ada hal-hal multimodal,
00:44:33seperti Anda perlu mengindeks gambar, tabel, dan video, dan Anda mengintegrasikan semacam sistem agen
00:44:40di mana ia bisa memutuskan secara cerdas jalur mana yang harus ditempuh untuk menjawab informasi.
00:44:47Karena di Level 7 Anda mungkin mengintegrasikan semua ini; Anda mungkin punya file Claude MD
00:44:52dengan beberapa informasi permanen, Anda mungkin memilikinya di basis kode dengan beberapa file Markdown
00:44:57untuk pengambilan yang mudah; mungkin Anda juga menyertakan Obsidian di semacam vault,
00:45:01ditambah lagi Anda mungkin punya bagian dokumen yang ada di database GraphRAG,
00:45:07dan Anda punya sistem AI di bagian atas yang bisa memutuskan, jika mereka menanyakan pertanyaan ini,
00:45:12saya akan lewat rute ini. Itulah arsitektur memori yang matang yang saya sarankan. Tapi apa jebakannya?
00:45:18Jebakannya sejujurnya adalah mencoba memaksakan diri ke level ini dan kecanggihan semacam ini
00:45:24padahal itu tidak dibutuhkan. Sejujurnya, setelah semua ini, sebagian besar dari Anda cukup dengan Obsidian;
00:45:28itu sudah lebih dari cukup, Anda tidak butuh GraphRAG, Anda benar-benar tidak butuh RAG secara umum.
00:45:34Dan jika tidak jelas bahwa Anda butuh Level 7, dan pastinya jika Anda belum mencoba rute Obsidian,
00:45:39Anda tidak perlu berada di sini. Itu mungkin hanya membuang-buang waktu Anda. Tapi tujuan dari video ini
00:45:43adalah, sejauh kemampuan saya, untuk memaparkan kepada Anda apa yang saya lihat sebagai level RAG
00:45:47dan memori yang berbeda dan Claude Code, serta apa masalahnya, apa ketegangannya,
00:45:52apa komprominya, dan di mana Anda seharusnya berada untuk kasus penggunaan Anda. Dan sekali lagi,