- RAG yang digunakan dalam AI berbasis pengetahuan kerja dapat kehilangan konteks seperti nama perusahaan atau waktu saat membagi dokumen menjadi chunk kecil, sehingga informasi relevan bisa terlewat
- Contextual Retrieval dari Anthropic adalah metode yang menambahkan deskripsi singkat berbasis keseluruhan dokumen di depan setiap chunk, lalu membuat embedding dan indeks BM25 untuk menurunkan tingkat kegagalan pencarian
- Dalam eksperimen, Contextual Embeddings menurunkan tingkat kegagalan pencarian chunk top-20 dari 5,7% menjadi 3,7%, turun 35%, dan kombinasi Contextual Embeddings dengan Contextual BM25 menurunkannya menjadi 2,9%, turun 49%
- Jika ditambah reranking, kandidat top-150 diberi skor ulang dan hanya top-20 yang diteruskan ke model, sehingga tingkat kegagalan pencarian turun dari 5,7% menjadi 1,9%, turun 67%
- Jika knowledge base berukuran 200.000 token atau kurang, memasukkan seluruhnya ke prompt juga memungkinkan, tetapi untuk knowledge base yang lebih besar, kombinasi Contextual Retrieval dan reranking perlu dievaluasi per use case
Konteks dokumen yang hilang oleh RAG
- Agar model AI berguna untuk pekerjaan tertentu, model harus dapat mengakses pengetahuan latar belakang
- Chatbot dukungan pelanggan membutuhkan pengetahuan bisnis terkait
- Bot analisis hukum membutuhkan pengetahuan tentang putusan pengadilan sebelumnya
- Developer biasanya memperkuat pengetahuan model dengan Retrieval-Augmented Generation(RAG)
- Mencari informasi relevan dari knowledge base
- Menambahkan informasi yang ditemukan ke prompt pengguna untuk meningkatkan respons model
- RAG konvensional dapat gagal menemukan informasi relevan karena menghapus konteks saat membagi dokumen menjadi chunk
- Contextual Retrieval adalah cara untuk memperbaiki tahap pencarian dalam RAG, dan dua teknik turunannya dapat digunakan bersama
- Contextual Embeddings: membuat embedding dari chunk yang sudah ditambahi konteks
- Contextual BM25: membuat indeks BM25 dari chunk yang sudah ditambahi konteks
- Kombinasi ini mengurangi jumlah kegagalan pencarian sebesar 49%, dan jika digabungkan dengan reranking dapat menguranginya hingga 67%
- Tersedia cookbook untuk menerapkan Contextual Retrieval dengan Claude
Untuk knowledge base kecil, prompt panjang juga memungkinkan
- Jika knowledge base berukuran 200.000 token atau kurang, kira-kira lebih kecil dari 500 halaman, seluruh knowledge base dapat dimasukkan ke prompt tanpa RAG
- prompt caching Claude membuat pendekatan ini lebih cepat dan hemat biaya
- Prompt yang sering digunakan dapat di-cache antar panggilan API
- Latensi dapat dikurangi hingga lebih dari 2 kali
- Biaya dapat dikurangi hingga 90%
- Cara kerjanya dapat dilihat di prompt caching cookbook
- Jika knowledge base makin besar, diperlukan metode pencarian yang lebih skalabel, dan saat itulah Contextual Retrieval digunakan
Peran RAG umum dan BM25
- Saat knowledge base besar tidak muat di context window, solusi umum adalah RAG
- Alur preprocessing RAG adalah sebagai berikut
- Membagi korpus dokumen menjadi chunk teks kecil, biasanya beberapa ratus token atau kurang
- Mengubah chunk menjadi vector embedding yang memuat makna dengan model embedding
- Menyimpan embedding di vector database yang memungkinkan pencarian kemiripan semantik
- Saat runtime, chunk yang paling mirip secara semantik dengan kueri pengguna dicari dari vector database, lalu chunk relevan ditambahkan ke prompt model generatif
- Model embedding sangat baik menangkap relasi semantik, tetapi bisa melewatkan kecocokan string yang persis
- BM25(Best Matching 25) adalah fungsi pemeringkatan yang menggunakan kecocokan kosakata, dan sangat efektif untuk kueri yang memuat identifier unik atau istilah teknis
- BM25 berbasis konsep TF-IDF
- TF-IDF mengukur seberapa penting kata tertentu dalam sebuah dokumen di dalam koleksi
- BM25 mempertimbangkan panjang dokumen dan menerapkan fungsi saturasi pada term frequency agar kata umum tidak mendominasi hasil
- Misalnya, saat mencari
"Error code TS-999" di database dukungan teknis, model embedding mungkin menemukan dokumen kode error umum tetapi melewatkan kecocokan persis "TS-999"
- BM25 menemukan string tersebut secara langsung dan mengidentifikasi dokumen terkait
RAG yang menggunakan embedding dan BM25 bersama
- RAG dapat menggabungkan embedding dan BM25 untuk menemukan chunk yang lebih akurat
- Membagi knowledge base menjadi chunk kecil
- Membuat encoding TF-IDF dan embedding semantik untuk setiap chunk
- Menemukan chunk teratas berbasis kecocokan persis dengan BM25
- Menemukan chunk teratas berbasis kemiripan semantik dengan embedding
- Menggabungkan hasil dengan teknik rank fusion dan menghapus duplikasi
- Memasukkan K chunk teratas ke prompt untuk menghasilkan respons
- Pendekatan ini menyeimbangkan kecocokan istilah yang persis dengan pemahaman makna yang lebih luas
- Dapat diskalakan secara hemat biaya hingga knowledge base sangat besar yang tidak bisa dimuat dalam satu prompt
- Namun, sistem RAG konvensional punya keterbatasan karena merusak konteks saat membagi dokumen menjadi chunk
- Contoh representatifnya adalah situasi bertanya
"What was the revenue growth for ACME Corp in Q2 2023?" pada knowledge base berbasis laporan SEC
- Chunk yang relevan mungkin hanya berisi
"The company's revenue grew by 3% over the previous quarter."
- Dari chunk ini saja, tidak diketahui perusahaan dan periode mana yang dimaksud
- Sulit memanfaatkan informasi yang benar baik pada tahap pencarian maupun penggunaan
Cara kerja Contextual Retrieval
- Contextual Retrieval menambahkan konteks deskriptif per chunk di depan setiap chunk sebelum membuat embedding dan indeks BM25
- Jika diterapkan pada embedding: Contextual Embeddings
- Jika diterapkan pada indeks BM25: Contextual BM25
- Dalam contoh laporan SEC, chunk aslinya adalah sebagai berikut
The company's revenue grew by 3% over the previous quarter.
- Chunk yang dikontekstualisasikan berubah seperti berikut
This chunk is from an SEC filing on ACME corp's performance in Q2 2023; the previous quarter's revenue was $314 million. The company's revenue grew by 3% over the previous quarter.
- Sebelumnya juga pernah diusulkan berbagai cara memanfaatkan konteks untuk meningkatkan pencarian
- Metode-metode ini berbeda dari pendekatan Contextual Retrieval yang menambahkan konteks per chunk
Membuat konteks chunk dengan Claude
- Memberi anotasi secara manual pada ribuan atau jutaan chunk tidak realistis
- Anthropic menulis prompt agar Claude membuat konteks singkat dan spesifik untuk tiap chunk yang menjelaskan setiap chunk berdasarkan konteks keseluruhan dokumen
- Prompt yang digunakan pada Claude 3 Haiku adalah sebagai berikut
<document>
{{WHOLE_DOCUMENT}}
</document>
Here is the chunk we want to situate within the whole document
<chunk>
{{CHUNK_CONTENT}}
</chunk>
Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk. Answer only with the succinct context and nothing else.
- Teks konteks yang dihasilkan biasanya 50~100 token, lalu ditambahkan di depan chunk dan digunakan untuk membuat embedding dan indeks BM25
- Dengan prompt caching, dokumen referensi tidak perlu dikirim ulang untuk setiap chunk
- Dokumen dimasukkan ke cache sekali dan konten yang sebelumnya sudah di-cache dirujuk
- Dengan asumsi chunk 800 token, dokumen 8k token, instruksi konteks 50 token, dan konteks 100 token per chunk, biaya satu kali untuk pembuatan chunk berkonteks adalah 1,02 dolar AS per 1 juta token dokumen
Metode eksperimen dan performa pencarian
- Eksperimen dilakukan di berbagai domain pengetahuan, model embedding, strategi pencarian, dan metrik evaluasi
- Codebase
- Novel
- Paper ArXiv
- Paper ilmiah
- Contoh pertanyaan dan jawaban dari tiap domain disertakan dalam Appendix II
- Grafik menunjukkan performa rata-rata di semua domain pengetahuan, menggunakan konfigurasi embedding teratas Gemini Text 004 dan pencarian chunk top-20
- Metrik evaluasinya adalah 1 - recall@20
- Mengukur proporsi dokumen relevan yang gagal ditemukan dalam 20 chunk teratas
- Dari hasil keseluruhan, semua kombinasi embedding-source yang dievaluasi menunjukkan peningkatan performa saat kontekstualisasi diterapkan
- Hasil peningkatan performanya adalah sebagai berikut
- Contextual Embeddings: menurunkan tingkat kegagalan pencarian chunk top-20 dari 5,7% → 3,7%, yaitu 35%
- Contextual Embeddings + Contextual BM25: menurunkan tingkat kegagalan pencarian dari 5,7% → 2,9%, yaitu 49%
Hal yang perlu dipertimbangkan saat implementasi
- Batas chunk dapat memengaruhi performa pencarian
- Ukuran chunk
- Batas chunk
- Overlap chunk
- Contextual Retrieval meningkatkan performa pada semua model embedding yang diuji, tetapi besarnya peningkatan bisa berbeda per model
- Embedding Gemini dan embedding Voyage terbukti sangat efektif
- Prompt umum yang disediakan bekerja dengan baik, tetapi hasil yang lebih baik bisa diperoleh dengan prompt contextualizer kustom yang disesuaikan dengan domain atau use case
- Contoh: menyertakan glossary istilah kunci yang hanya didefinisikan di dokumen lain dalam knowledge base
- Memasukkan lebih banyak chunk ke context window meningkatkan kemungkinan informasi relevan tercakup
- Namun, semakin banyak informasi dapat membuat model terdistraksi, sehingga ada batasnya
- Dari pengujian mengirim 5, 10, dan 20 chunk, 20 chunk memberikan performa terbaik
- Dalam use case nyata, eksperimen tetap diperlukan
- Untuk pembuatan respons, mengirim chunk berkonteks dan membedakan mana konteks dan mana chunk asli dapat memberikan peningkatan
- Evaluasi harus selalu dijalankan
Peningkatan tambahan dengan reranking
- Reranking adalah teknik filtering pada knowledge base besar yang hanya meneruskan chunk paling relevan dari kandidat chunk hasil pencarian awal ke model
- Tahap ini dapat memengaruhi kualitas respons, biaya, dan latensi dengan mengurangi jumlah informasi yang diproses model
- Prosedurnya adalah sebagai berikut
- Mengambil chunk teratas yang berpotensi relevan melalui pencarian awal
- Dalam eksperimen digunakan top 150
- Meneruskan N chunk teratas dan kueri pengguna ke model reranking
- Model reranking memberi skor relevansi dan kepentingan pada setiap chunk
- Memilih K chunk teratas
- Dalam eksperimen digunakan top 20
- Memasukkan chunk terpilih ke konteks model untuk menghasilkan hasil akhir
- Eksperimen dilakukan dengan Cohere reranker
- Ada juga Voyage reranker, tetapi tidak sempat diuji
- Menambahkan tahap reranking di berbagai domain membuat pencarian lebih optimal
- Reranked Contextual Embedding + Contextual BM25 menurunkan tingkat kegagalan pencarian chunk top-20 dari 5,7% → 1,9%, yaitu 67%
Menyeimbangkan biaya dan latensi
- Karena reranking menambahkan tahap ekstra saat runtime, ia pasti menambahkan sedikit latensi
- Walaupun model reranking memberi skor semua chunk secara paralel, dampak latensi dan biaya tetap perlu dipertimbangkan
- Mereranking lebih banyak chunk dapat meningkatkan performa, tetapi biaya dan latensi bertambah
- Mereranking lebih sedikit chunk menurunkan biaya dan latensi, tetapi peningkatan performanya bisa berkurang
- Keseimbangan yang tepat harus ditemukan dengan mencoba beberapa konfigurasi pada use case tertentu
Hasil saat dikombinasikan
- Berbagai kombinasi jenis dataset, model embedding, penggunaan BM25, penggunaan Contextual Retrieval, penggunaan reranking, dan jumlah pencarian top-K dibandingkan
- Ringkasan hasilnya adalah sebagai berikut
- Embeddings + BM25 lebih baik daripada embedding saja
- Di antara embedding yang diuji, Voyage dan Gemini adalah yang terbaik
- Mengirim chunk top-20 ke model lebih efektif daripada top-10 atau top-5
- Menambahkan konteks ke chunk sangat meningkatkan akurasi pencarian
- Reranking lebih baik daripada tidak menggunakan reranking
- Untuk memaksimalkan peningkatan performa, dapat digabungkan Contextual Embeddings berbasis Voyage atau Gemini, Contextual BM25, tahap reranking, dan penambahan 20 chunk ke prompt
- Developer dapat mencoba pendekatan ini melalui Contextual Retrieval cookbook
1 komentar
Opini Hacker News
Sedang membangun RAG enterprise untuk lembaga pemerintah. Setelah melakukan uji A/B eksperimental dengan metrik RAGAS, berdasarkan pertanyaan evaluasi sintetis, tidak ada perubahan besar meski reranking berbasis LLM ditambahkan setelah pencarian hybrid (pencarian semantik + vektor), sementara HyDE justru menurunkan kualitas jawaban dan kualitas pencarian secara signifikan.
Evaluasi RAGAS dengan pertanyaan dari pakar dan pertanyaan pengguna nyata masih perlu dilakukan lebih lanjut.
Jadi, di RAG operasional/enterprise, pencarian hybrid selalu bagus bukanlah hal baru, tetapi satu metode tidak selalu menang. Dalam kasus kami, pencarian semantik Azure AI Search saja sudah cukup sebagai metode kedua di samping kemiripan vektor. Di tempat lain, BM25 atau small language model pascapemrosesan kueri yang di-fine-tune mungkin lebih baik, jadi pada akhirnya harus terus diuji per use case.
Berikutnya kami berencana mencoba RAPTOR, SelfRAG, RAG agentic, perbaikan kueri (ekspansi dan subkueri), serta GraphRAG.
Pelajaran sejauh ini adalah kita harus memiliki baseline dan kelompok eksperimen, lalu mencoba membantah hipotesis nol dengan metrik seperti RAGAS; pertanyaan/jawaban evaluasi sebaiknya memakai tiga jenis: Q&A yang ditulis pakar, pertanyaan pengguna nyata dari log, dan Q&A sintetis yang dibuat dari dokumen asli.
Hal yang paling saya sukai dari pendekatan ini adalah pemanfaatan prompt caching yang baik.
Prompt yang di-cache biasanya biayanya sekitar 1/10 dari biaya normal, jadi trik seperti menjalankan semua chunk bersama seluruh dokumen asli dulu tidak masuk akal dari sisi biaya, tetapi sekarang menjadi memungkinkan.
Berkat penghematan biaya dari caching, sepertinya akan ada lebih banyak teknik bagus seperti ini yang terbuka.
Catatan tentang contextual retrieval: https://simonwillison.net/2024/Sep/20/introducing-contextual... dan catatan prompt caching: https://simonwillison.net/2024/Aug/14/prompt-caching-with-cl...
Ini sepertinya konteks yang berguna untuk memperkirakan berapa banyak biaya yang perlu dikeluarkan agar bisa mengikuti model dan fitur terbaru.
Dari latar belakang pencarian tradisional, membatasi RAG hanya pada model embedding siap pakai dan pencarian vektor terlihat seperti strategi yang cukup naif. Pencarian vektor sendiri tidak sebagus itu, dan untuk memperbaiki konteks yang diberikan ke LLM, diperlukan strategi information retrieval tambahan. Yang dilakukan di sini pada dasarnya adalah hal itu.
Microsoft dulu menerbitkan paper Graph RAG, yang menggabungkan RAG dan pencarian vektor berdasarkan graph konsep yang dibuat lewat ekstraksi entitas dari data indeks. Dengan cara ini, informasi yang relevan secara kontekstual dengan chunk yang cocok bisa ditarik masuk.
Saya merasa kita bisa melangkah cukup jauh bahkan tanpa pencarian vektor. Biayanya juga jauh lebih murah. Cukup memakai mesin pencari tradisional dan kueri yang disetel dengan baik. Tentu saja intinya adalah tuning kueri, dan mungkin tidak cocok untuk kasus umum, tetapi bisa berhasil untuk kasus yang lebih khusus.
Sebagai tambahan konteks, pendekatan ini tidak terlalu baru. Salah satu cara umum untuk meningkatkan hasil RAG adalah “memperluas” chunk dasar dengan LLM agar luas permukaan semantik yang bisa dicocokkan bertambah.
Jika menjalankan ekspansi kueri dengan HyDE[1], hasilnya juga bisa lebih baik, tetapi tidak selalu membaik, jadi saya memakainya sebagai jalur alternatif.
Saya tidak yakin apa hal baru yang Anthropic hadirkan di sini. Melihat kode cookbook-nya pun hanya menunjukkan proses pembuatan konteks tersebut, dan tidak ada perubahan API nyata terkait “contextual retrieval”.
Yang berubah adalah prompt caching yang diperkenalkan sebulan lalu, yang memungkinkan pemberian seluruh dokumen panjang sebagai konteks dan menambahkan konteks yang lebih baik ke tiap chunk dengan sangat murah. Caching adalah fitur luar biasa yang bagus untuk dibuka kepada developer, dan saya mengakui nilainya.
Namun selain itu, yang terlihat hanyalah cookbook yang menunjukkan workflow RAG tertentu.
Sebagai tambahan, Cohere termasuk API yang paling saya sukai di antara yang pernah saya pakai. Saya tidak berafiliasi, dan Cohere RAG API sangat bagus dibanding penyedia lain. Sangat direkomendasikan.
1: https://arxiv.org/abs/2212.10496
Jika data memiliki puluhan ribu chunk, semua ini harus dilakukan sehingga biayanya besar. Dengan meng-cache dokumen, biaya itu bisa dikurangi.
Itu kurang cocok untuk kebutuhan RAG saya, dan mungkin kebanyakan orang juga sama. Sebab kueri bisa dijalankan bulan depan atau setahun kemudian. Sepertinya kebijakan itu juga belum berubah, jadi agak mengejutkan melihat Prompt Caching dibicarakan dalam konteks RAG.
Kami juga melakukan hal yang mirip. Pertama, dokumen dipecah menjadi chunk berdasarkan judul h1, h2, h3, lalu header ditempelkan sebagai konteks di awal chunk
Sebagai contoh hipotetis, jika chunk aslinya berbunyi “Dosis umum untuk orang dewasa adalah 1–2 tablet atau kapsul 200mg, 3 kali sehari”, sekarang isinya menjadi
# Fever,## Treatment, lalu konten yang sama setelah garis pemisahSepertinya bekerja cukup baik, dan saat mengindeks dokumen juga tidak perlu LLM
Ini mungkin juga asal mula perdebatan “ChatGPT melambat pada bulan Desember”. Metadata “tanggal” itu bisa saja memberi sinyal kepada ChatGPT agar kurang membantu
Pertama, setiap halaman diringkas, diberi judul, dan daftar subbagiannya diekstrak. Lalu semua ringkasan digabung dan model diminta membuat indeks hierarkis. Model menyusun seluruh kumpulan menjadi pohon, dan pada saat kueri, jalur di dalam pohon digabungkan sebagai konteks tambahan
Saya kurang suka teknik ini. Saya setuju skenario yang diajukan adalah masalah yang umum, tetapi solusi yang diusulkan terasa canggung
Vector embedding memiliki sifat seperti kompresi bag-of-words, dan bisa terindeks secara berlebihan pada blok teks baris baru pertama. Akibatnya, indeks tertentu pada vektor bisa menjadi jauh lebih dekat ke 0 daripada semestinya. Setelah melalui kuantisasi, pada akhirnya bisa menjadi 0, sehingga banyak presisi pada dense vector hilang. Pencarian IDF memang membantu sampai batas tertentu, tetapi tidak cukup
Jika embedding “di-boost secara semantik” agar bergerak lebih dekat ke judul dokumen, ringkasan, abstrak, dan sebagainya, kita bisa mendapatkan manfaat recall dari prefiks “konteks” ini tanpa mencemari vektor dasar. Dari sisi implementasi, ini berupa jumlah berbobot. Pada tahap augmentasi, ketika dokumen cocok saat dimasukkan ke context window, chunk ringkasannya juga bisa ikut disuntikkan. Menurut saya pribadi, ini solusi yang jauh lebih bersih
Penjelasan “semantic boost” dari Trieve API[1]:
semantic_boost: berguna untuk menggeser vector embedding sebuah chunk ke arah frasa jarak. Misalnya, chunk denganchunk_htmlberupaiphonedapat didorong 25% lebih dekat ke istilah “flagship” dengan memakaiflagshipsebagaidistance_phrasedan0.25sebagaidistance_factor. Secara konseptual, ini menggambar garis jarak Euclidean/L2 antara vektorinnerTextdarichunk_htmldan vektordistance_phrase, lalu di sepanjang garis itu menggeser vektorchunk_htmllebih dekat atau lebih jauh sebesardistance_factorL2Distance[1]:https://docs.trieve.ai/api-reference/chunk/create-or-upsert-...
Kalau begitu, bukankah itu berarti vector DB akan terikat pada satu LLM, bahkan satu versi tertentu seperti Claude-3.5 Sonnet, tidak bisa dipindahkan ke 3.5 Haiku atau Opus, dan jika ingin beralih ke ChatGPT atau Llama perlu reindexing?
Teknik yang menurut saya paling berguna adalah menerapkan strategi linked list, di mana sebuah chunk memiliki banyak pointer dari item-item yang merujuk kepadanya. Saya melakukan ini secara manual, tetapi keragaman cara untuk merujuk ke node tertentu meningkat besar
Dilihat dengan cara lain, ini seperti komentar. Semua komentar di bawah tulisan ini bisa dianggap sebagai pointer yang mengarah ke tulisan asli. Sebagian komentar memiliki jarak makna yang dekat dengan tulisan asli, sebagian lagi lebih jauh karena persepsi penulisnya. Namun jika setiap komentar diberi
parent_id, jalur untuk mengakses tulisan asli bertambahContoh teknik ini bisa dilihat di sini [1]. Alih-alih mencoba menebak kueri apa yang akan diajukan pengguna akhir, cukup biarkan pengguna mengatakannya lalu indeks itu sebagai pointer. Pilihan untuk merepresentasikan suatu objek memang terbatas, tetapi sebagian representasi bisa sangat, sangat, sangat jauh dari makna objek intinya
[1] - https://x.com/yourcommonbase/status/1833262865194557505
Pernyataan bahwa pada dataset kecil kita cukup memasukkan 200 ribu token untuk mendapatkan jawaban terbaik tidak sesuai dengan pengalaman saya
Saya sering melihat semakin besar prompt, semakin turun konsistensi output, dan kemampuan mengikuti instruksi juga memburuk. Bahkan hal ini tampaknya terjadi pada rentang yang jauh lebih kecil dari 25k token. Saya penasaran apakah orang lain juga mengalaminya, dan apakah ada cara yang sudah dikenal untuk menghindarinya
Menarik. Masalah yang saya hadapi adalah mencari aturan yang bisa diterapkan dengan RAG, bukan potongan pengetahuan. Hanya aturan yang dapat diterapkan pada kontekslah yang harus disuntikkan ke dalam konteks
Saya belum bereksperimen, tetapi menurut saya pendekatan melatih classifier kecil untuk menilai apakah aturan tertentu bisa diterapkan mungkin berhasil. LLM utama bertugas menilai apakah aturan itu benar-benar berlaku dalam konteks saat ini
Misalnya, bayangkan kita memainkan game dungeon multipengguna dengan LLM. Katakanlah dulu karakternya pernah berperilaku buruk terkait taksi, lalu game membuat aturan: “setiap kali mencoba naik taksi, ia akan diusir. ‘Kami tahu siapa Anda, dan sampai Anda meminta maaf secara resmi kepada direktur perusahaan taksi, kami tidak akan menerima Anda sebagai pelanggan’”. Jika ia meminta maaf, aturan itu dihapus. Direktur perusahaan taksi bisa saja pemain lain, atau orang yang pertama kali memicu aturan yang akan ditegakkan oleh armada taksi NPC miliknya
Saya penasaran sejauh apa ini bisa diskalakan berdasarkan jumlah aturan aktif, dan seberapa jauh RAG tradisional bisa diterapkan. Menilai apakah suatu aturan berlaku tampaknya merupakan masalah yang lebih abstrak dan sulit daripada menilai apakah potongan pengetahuan relevan
Hal utama yang membuatnya lebih sulit adalah adanya loop dependensi yang tidak ada dalam pencarian pengetahuan. Untuk mengidentifikasi apakah sebuah aturan berlaku, aturan itu harus dicari terlebih dahulu. Bagaimana cara memecahkan masalah ini?
Contoh kueri, jika ditulis dengan bantuan LLama 3.1 8B, bisa dibuat cukup detail: pasukan dark elf mendekat, Grimgold Ironfist berada dalam situasi putus asa, dulu merupakan anggota membanggakan milisi dwarf tetapi kini kesehatannya tinggal 35%, inventarisnya berisi beliung tua, ember air, roti lama, dan 17 koin emas, dan meski punya “masa lalu bermasalah” dengan guild taksi, ia mencoba menghentikan taksi di jalan
Contoh aturan yang akan diambil dari vector store kemungkinan akan ditemukan karena ada kedekatan vektor dari penyebutan nama/atribut karakter serta taksi dan Taxi Guild
Aturannya bisa seperti: “Taxi Guild telah menjatuhkan hukuman ketat kepada Grimgold. Setiap kali ia mencoba menghentikan taksi, ia langsung diusir dari kendaraan. Dekret Guild menyatakan, ‘Grimgold Ironfist, dwarf berjanggut yang bereputasi buruk, tidak boleh menaiki taksi mana pun yang dioperasikan anggota sampai ia meminta maaf secara resmi kepada Thorgrim Stonebeard, direktur Golden Horse Cab Company. Jika tidak mematuhi ini, ia akan dikeluarkan secara permanen dari layanan kami’”
Mereka mengatakan “jika basis pengetahuannya lebih kecil dari 200.000 token (sekitar 500 halaman)”, tetapi saya berharap Anthropic merilis tokenizer saja. Supaya kita tidak perlu menebak-nebak
Saya sedang menunggu hari ketika seluruh industri AI berputar satu putaran penuh dan akhirnya kembali ke TF-IDF