LlamaIndex: Panduan

Panduan ini akan mengajarkan cara membangun knowledge base RAG dengan LlamaIndex. Kita akan melihat dari awal, dari mengambil dokumen hingga membuat query. Fokusnya adalah pada penggunaan di Indonesia.

LlamaIndex adalah sistem yang menghubungkan model bahasa besar dengan dokumen. Ini memungkinkan tim untuk membuat fitur seperti tanya jawab dan ringkasan dokumen. Mereka juga bisa membuat penalaran multi-langkah dan agen yang berinteraksi dengan sistem lain.

Dalam tutorial ini, kita akan membandingkan LlamaIndex dengan alat lain. Kita juga akan melihat praktik produksi yang efektif. Topik yang akan dibahas termasuk ekosistem LlamaIndex, komponen utama, dan cara membuat knowledge base.

Panduan ini cocok untuk implementasi lokal. Kita bisa menggunakan model open-source seperti Ollama atau layanan model-hosted seperti OpenAI. Kita juga akan membahas pilihan database vektor yang sesuai dengan kebutuhan kita.

Meta title: LlamaIndex: Cara Bangun Knowledge Base untuk RAG dengan Cepat. Pelajari cara mempercepat pembuatan knowledge base dengan LlamaIndex. Bandingkan dengan alat lain dalam tutorial ini.

Apa Itu LlamaIndex?

LlamaIndex adalah sistem yang menghubungkan model bahasa besar dengan dokumen pengguna. Ini menggunakan pola Retrieval-Augmented Generation. Sistem ini membuat dokumen diurai, di-chunk, dan diubah menjadi embedding yang disimpan di vector store.

Ini memudahkan pengambilan cepat saat ada kueri. Fungsionalitas utama dari llamaindex adalah parsing dokumen dan pembuatan potongan teks. Kemudian, membuat embedding dan menyimpannya di vector store.

Ini juga mengambil konteks relevan dan memanggil LLM untuk jawaban atau tindakan. Desainnya mendukung workflow agen, sehingga sistem bisa otomatis melakukan tugas berdasarkan konteks dokumen.

Framework ini tersedia sebagai pustaka open-source untuk Python dan TypeScript. Ada juga pilihan komersial lewat layanan terkelola LlamaCloud. Layanan ini menawarkan penguraian dokumen, pengindeksan, pengambilan, dan layanan agen tanpa perlu pengaturan infrastruktur penuh.

Salah satu kelebihan dari LlamaIndex adalah kemampuan mengakses dokumen pribadi tanpa perlu melatih ulang model. Dengan pendekatan RAG, jawaban menjadi lebih akurat dan referensial. Jawaban juga dapat dilacak ke sumber dokumen asli.

LlamaIndex bersifat LLM-agnostic, mendukung embedding lokal maupun hosted. Ini mendukung model lokal seperti Llama 3.1 via Ollama atau melalui API OpenAI dan Anthropic. Ini sesuai dengan kebutuhan operasional dan kebijakan data.

Dalam praktiknya, teknologi ini cocok untuk sistem support berbasis FAQ, analisis kontrak, dan knowledge base internal. Menggunakan llamaindex dan layanan LlamaCloud mempermudah tim produk dan data. Mereka bisa menghadirkan jawaban yang lebih kontekstual dan dapat diaudit dari sumber perusahaan.

Konsep Inti: Nodes, Index, Query Engine

Nodes adalah unit terkecil yang merepresentasikan potongan dokumen di LlamaIndex. Setiap node menyimpan blok teks terstruktur, metadata, dan referensi ke sumber asli. Ini membuat rekonstruksi konteks menjadi mudah.

Peran node parser sangat penting saat memproses file mentah. File seperti PDF, spreadsheet, email, atau gambar diubah menjadi objek terstruktur. Ini memastikan LLM menerima teks terformat dengan baik.

Index menyimpan nodes dan embedding untuk pencarian cepat. VectorStoreIndex adalah implementasi umum yang menggunakan penyimpanan vektor seperti Milvus. Ini memungkinkan pencarian berbasis embedding yang efisien.

Pengaturan embed model menentukan kualitas embedding. Model seperti BAAI/bge-base-en-v1.5, dari HuggingFace, dan OpenAI sangat populer. Pengaturan ini bisa disesuaikan secara global untuk konsistensi di seluruh index.

Storage context mengelola penyimpanan vektor dan metadata. Dengan StorageContext.persist(), index dapat disimpan ke disk. Ini memungkinkan penggunaan berkelanjutan di produksi dengan load_index_from_storage.

Query engine adalah antarmuka yang membungkus mekanisme pengambilan dan panggilan LLM. Dengan index.as_query_engine(), alur menjadi lebih sederhana. Ini mendukung mode sinkron dan asinkron melalui aquery.

Strategi retrieval pada query engine dapat disesuaikan. Misalnya, menggabungkan reranking atau filter metadata. Ini membantu menjaga relevansi hasil saat menjawab pertanyaan kompleks.

Integrasi storage context dengan connector vektor memungkinkan skalabilitas dan redundansi. LlamaIndex mendukung konektor populer. Ini memudahkan migrasi antara solusi seperti FAISS dan Pinecone tanpa menghentikan alur kerja.

Dalam keseluruhan, kombinasi node parser, nodes, index, dan query engine membentuk fondasi RAG yang modular. Memahami setiap elemen mempermudah desain pipeline yang andal untuk aplikasi nyata.

Ingestion Dokumen

Proses ingestion dokumen mengubah file mentah menjadi nodes yang bisa dicari dan diindeks. Ini memastikan kita bisa mengetahui asal sumber dan mempersiapkan dokumen untuk diproses oleh mesin pencari.

Untuk melakukan ingestion yang efektif, kita membutuhkan document loader. Misalnya, SimpleDirectoryReader(“data”).load_data() mengumpulkan data dari berbagai file. Ini membuat kita bisa melacak sumber dokumen dengan mudah.

Parser, Split, Metadata

Gunakan node parser seperti LlamaParse untuk menguraikan struktur dari berbagai format file. Ini termasuk PDF, DOCX, spreadsheet, HTML, dan gambar. Parser ini memahami tata letak kompleks dan menghasilkan teks atau objek yang bisa diketik.

Setelah itu, kita membagi dokumen menjadi potongan yang sesuai dengan konteks LLM. Pilih cara membagi berdasarkan paragraf atau tata letak. Ini memastikan ukuran potongan tetap seimbang dan relevan.

Setiap node harus memiliki metadata seperti sumber file, posisi dalam dokumen, tanggal, dan tag. Metadata ini memungkinkan kita melakukan filter dan pencarian berdasarkan atribut tertentu.

Untuk skala besar, simpan hasil ingestion di persist storage_context. Ini menghindari kita harus melakukan re-ingestion yang mahal. Atur LLAMA_INDEX_CACHE_DIR sebagai variable lingkungan untuk mengontrol cache paket lokal seperti NLTK atau Hugging Face.

Jika kita menghadapi volume data yang tinggi, gunakan asynchronous ingestion dan vector store. Misalnya, integrasi Milvus async. Pengujian menunjukkan bahwa metode ini jauh lebih cepat dibandingkan dengan metode sinkron pada penyimpanan vektor besar.

Membuat Vector Index dan Retriever

Membangun vector index dimulai dengan memilih model embedding yang tepat. Anda bisa memilih HuggingFaceEmbedding, OpenAI embeddings, atau BAAI/bge. Setelah itu, atur Settings.embed_model sebelum memulai proses indexing. Ini menentukan kualitas dan akurasi pencarian.

Untuk membuat index dari dokumen, gunakan API seperti VectorStoreIndex.from_documents(documents). Atau, buat StorageContext yang menunjuk ke vector store, seperti MilvusVectorStore. Simpan konfigurasi storage agar proses pembentukan index konsisten di lingkungan produksi.

Pilih vector store berdasarkan kebutuhan Anda. Milvus cocok untuk skala besar dan throughput tinggi. FAISS memberikan performa lokal yang cepat. Chroma nyaman untuk pengembangan lokal dengan kebutuhan sederhana. Pertimbangkan juga konsistensi, kemampuan asinkron, dan biaya operasional.

Contoh inisialisasi MilvusVectorStore melibatkan beberapa parameter. Anda perlu menentukan uri, dim, collection_name, similarity_metric, dan consistency_level. Milvus mendukung metode async_add dan aquery untuk menambah data dan melakukan pencarian dengan throughput tinggi. Benchmark menunjukkan operasi asinkron jauh lebih efisien untuk skala besar.

Retriever dibuat dari index menggunakan index.as_retriever() atau index.as_query_engine().as_retriever(). API ini mengembalikan top-k chunks berdasarkan embedding dan skor match. Retriever dapat dikonfigurasi untuk hybrid search yang menggabungkan pencocokan vektor dan keyword untuk hasil lebih relevan.

Mode retrieval di LlamaIndex memberi fleksibilitas. Anda bisa memilih chunk sebagai mode default, file_via_metadata untuk mengambil berdasarkan metadata, file_via_content untuk mengambil isi dokumen penuh, atau auto_routed saat agen memutuskan mode terbaik. Mode ini membantu menyeimbangkan latensi dan relevansi jawaban.

Persistensi penting untuk pipeline produksi. Simpan index dan storage_context ke disk dengan storage_context.persist(“storage”). Ini memungkinkan pemulihan cepat dan integrasi lintas layanan yang mulus. Praktik ini mengurangi waktu startup dan mempercepat deployment.

Ringkasnya, keputusan tentang vector index, retriever, dan vector store mempengaruhi arsitektur keseluruhan. Rancang pipeline embedding, pilih vector store yang sesuai seperti Milvus, FAISS, atau Chroma, lalu konfigurasikan retriever untuk mencapai keseimbangan antara relevansi dan performa.

Query Engine: RAG end-to-end

Alur RAG dimulai dari user query. Kemudian, retriever mencari vektor atau hybrid. Setelah itu, storage context yang relevan dikumpulkan.

Hasil kumpulan konteks di-inject ke prompt LLM. Ini membuat jawaban lebih terintegrasi dengan bukti dokumen. LlamaIndex mempermudah langkah ini dengan query engine yang bisa dipanggil langsung dari index.

Untuk implementasi praktis, buat query_engine = index.as_query_engine(use_async=True, llm=OpenAI(…)). Mode asinkron mempercepat pipeline dan memudahkan skala. Panggilan aquery() kemudian mengembalikan response yang berisi sintesis jawaban berdasarkan konteks yang diambil oleh retriever.

Auto-routing menambah fleksibilitas. Dalam mode Auto_Routed, agen ringan memilih strategi pengambilan terbaik per kueri. Opsi ini meningkatkan akurasi retrieval untuk permintaan kompleks tanpa konfigurasi manual.

Pembungkusan retrieval sebagai tool memperluas kemampuan agen. Contoh FunctionAgent dipasangkan dengan alat search_documents. Agen memutuskan kapan menggunakan retrieval atau memanggil alat lain seperti kalkulator. Pola ini membuat RAG + agen cocok untuk alur kerja multi-step dan tugas berbasis tindakan.

Untuk skenario produksi, persistensi penting. Setelah indeks dibuat, simpan ke disk agar tidak perlu re-indexing. Pada layanan seperti LlamaCloud, unggah file dan jalankan financial_index.wait_for_completion() sebelum menggunakan retriever dalam sistem live.

Kualitas jawaban bergantung pada pemilihan potongan yang relevan. Ukuran konteks yang diberikan ke LLM dan prompt engineering juga penting. Gunakan limit top_k dan mekanisme reranking bila perlu untuk menurunkan noise dan meningkatkan keakuratan.

Reranking dan Post-processing

Reranking bertujuan memperbaiki urutan hasil yang dikembalikan oleh retriever sebelum dikirim ke model bahasa. Saat retriever mengembalikan banyak hasil kurang relevan, reranker mengevaluasi potongan teks. Tujuannya untuk menurunkan noise dan meningkatkan relevansi.

Salah satu teknik umum adalah memadukan pembobotan kosinus dengan model sekunder. Model sekunder memberi skor ulang. Pilihan lain adalah menggunakan LLM-based reranker untuk menilai konteks dan niat pengguna.

Reranking bisa diterapkan langsung pada hit dari vector store. Ini memilih kandidat terbaik.

Filter metadata mempersempit ruang pencarian melalui atribut seperti tanggal, sumber, atau tag. Hybrid search menggabungkan pencarian vektor dan kata kunci. Ini penting untuk dokumen teknis yang mengandung istilah khusus.

Langkah post-processing diperlukan setelah LLM menghasilkan jawaban. Ini termasuk normalisasi format, ekstraksi fakta terstruktur, dan penyertaan kutipan sumber. Menyertakan skor kepercayaan membantu pengguna menilai kualitas keluaran.

Traceability dan audit menuntut pencatatan silsilah penggunaan nodes. Ini agar jawaban bisa dilacak. Praktik ini krusial untuk aplikasi hukum, kontrak, dan kepatuhan.

Pada alur berisiko tinggi, integrasi human-in-the-loop memperkenalkan titik persetujuan manusia. Agent Workflow mendukung event seperti InputRequiredEvent dan HumanResponseEvent. Ini menambah lapisan kontrol dan mengurangi potensi kesalahan.

Implementasi reranker llamaindex harus mempertimbangkan keseimbangan antara latensi dan kualitas. Konfigurasi reranking yang baik menurunkan beban pada LLM. Ini meningkatkan relevansi keluaran tanpa memperpanjang waktu respons secara signifikan.

Evaluasi RAG di LlamaIndex

Untuk evaluasi RAG, kita perlu memeriksa beberapa hal. Pertama, kita lihat metrik retrieval dan kualitas jawaban. Kita gunakan recall@k dan precision@k untuk tes kemampuan retriever.

Kemudian, kita ukur exact match dan F1 untuk jawaban yang akurat. Untuk tugas ringkasan, kita pakai BLEU atau ROUGE. Ini membantu kita menilai kualitas jawaban secara menyeluruh.

Kita juga perlu memisahkan evaluasi RAG menjadi dua bagian. Pertama, kita tes komponen seperti retriever, vektor store latency, dan konsistensi hasil. Kedua, kita tes end-to-end dengan memeriksa user satisfaction, waktu latensi, dan biaya API.

Untuk membandingkan model, kita lakukan A/B testing. Kita bandingkan model embedding seperti BAAI bge dan OpenAI embeddings dengan LLM seperti GPT-4, GPT-3.5, dan Claude. Kita catat trade-off antara akurasi, biaya, dan latensi.

Kita juga uji performa vektor store dengan metrik throughput dan latensi query. Misalnya, Milvus menunjukkan peningkatan throughput dengan operasi asinkron. Kita tambahkan pengukuran add/search asinkron untuk evaluasi yang lebih komprehensif.

Kita tes evaluasi agentic retrieval untuk kueri kompleks. Kita bandingkan mode auto_routed dengan chunk default untuk melihat apakah agen memilih jalur yang lebih baik. Kita dokumentasikan keputusan agen dan metrik RAG untuk analisis.

Kita juga lakukan pengujian skenario nyata seperti analisis risiko kontrak. Kita uji parsing akurasi, mapping klausa ke kebijakan, skor keparahan, dan waktu sampai output siap. Ini memberi gambaran jelas tentang performa RAG dalam konteks bisnis.

Kita terapkan monitoring dan observability pada pipeline. Kita catat event streaming agen, output alat, dan silsilah node untuk debugging. Kita gunakan log untuk mendeteksi data drift dan degradasi model, serta untuk memvalidasi metrics RAG secara terus-menerus.

Kita buat metrik laporan berkala yang menggabungkan retriever evaluation, quality metrics, dan biaya. Laporan ini membantu tim engineering dan produk mengambil keputusan berbasis data tentang tuning embedding, pemilihan LLM, dan optimasi vektor store.

Integrasi Tools/Agents

Integrasi alat dalam LlamaIndex membuat model besar menjadi agen yang melakukan tindakan nyata. Alat ini bisa melakukan berbagai fungsi, seperti kalkulator, pencarian dokumen, atau panggilan API eksternal. Bahkan, alat ini bisa berinteraksi dengan sistem CRM dan ERP.

FunctionAgent memungkinkan model menggunakan fungsi Python. Misalnya, ada tool untuk operasi matematika. Ini cocok jika LLM mendukung panggilan fungsi.

ReActAgent menggunakan pola reasoning-then-action tanpa memerlukan fungsi. Agen ini menulis langkah-langkah pemikiran dan aksi secara berurutan. Ini ideal untuk penalaran multi-langkah yang membutuhkan keputusan bercabang.

AgentWorkflow memungkinkan pengaturan beberapa agen dan alat dalam alur kerja terpadu. Anda bisa menggabungkan berbagai agen dengan data bersama. Ini membuat manajemen status dan konteks lebih mudah.

AgentWorkflow memancarkan streaming events untuk observability. Anda bisa melihat real-time apa yang terjadi. Ini mendukung human-in-the-loop dengan jeda untuk tinjauan atau persetujuan manual.

Di lingkungan Application Development Workbench (ADW), Anda bisa menghubungkan alat seperti webhook atau penulisan database. Pastikan deskripsi alat jelas agar LLM memutuskan tool calling dengan tepat.

Penerapan nyata memerlukan deskripsi alat yang jelas dan batasan akses. Strategi error handling juga penting. Pastikan Anda melakukan pengujian end-to-end untuk memastikan semua berjalan sesuai harapan.

Tips Produksi

Pilih model LLM yang cocok untuk kebutuhan Anda. LlamaIndex bisa digunakan dengan model lokal seperti Llama 3.1 untuk privasi. Atau, gunakan layanan hosted seperti OpenAI dan Anthropic untuk kemudahan.

Untuk embedding, pertimbangkan model domain-specific seperti BAAI bge-base-en-v1.5. Ini memastikan representasi vektor relevan dengan data Anda.

Untuk skala besar, gunakan Milvus production sebagai vector store terkelola. Anda juga bisa self-host dengan Zilliz Cloud. Milvus menawarkan konsistensi konfigurasi dan performa yang baik pada beban tinggi.

Untuk lingkungan lokal ringan, FAISS atau Chroma tetap cocok. Mereka hemat sumber daya.

Manfaatkan asinkron saat throughput tinggi. Atur index dengan use_async=True. Gunakan Milvus async_add atau aquery untuk insert dan query asinkron.

Benchmark internal menunjukkan pengurangan latensi dan waktu insert/query signifikan saat memakai mode ini.

Simpan StorageContext dan index ke disk untuk meminimalkan reingestion berulang. Terapkan jadwal re-embedding melalui cron atau webhook. Ini agar knowledge base tetap up to date tanpa downtime besar.

Cadangkan metadata dan konfigurasi secara berkala.

Amankan data sebelum unggah. Enkripsi dokumen sensitif, batasi akses dengan token dan whitelist IP. Aktifkan enkripsi data at-rest bila diperlukan.

Kebijakan akses harus jelas di level API dan storage. Ini untuk meminimalkan risiko kebocoran.

Implementasikan observability dan monitoring yang komprehensif. Log event agen, panggilan alat, dan silsilah dokumen. Gunakan streaming event dari AgentWorkflow untuk debugging real-time dan audit trail saat terjadi anomali.

Ikuti praktik engineering yang matang: tulis deskripsi alat yang jelas, batasi konteks memori pada pipeline, dan scale bertahap sesuai metrik. Pantau biaya API dan sertakan human-in-the-loop untuk keputusan berisiko tinggi. Uji fallback dan rate limit untuk menghindari gangguan produksi.

Pilih strategi deployment yang sesuai. Opsi lokal menggunakan Docker atau VPS cocok untuk kontrol penuh. Managed hosting lewat layanan seperti LlamaCloud mempercepat time-to-market. Integrasi UI umum meliputi Gradio, Streamlit, atau Next.js. Pada Jupyter/Colab gunakan nest_asyncio saat menjalankan kode asinkron agar loop tidak bentrok.

FAQ

Ringkasan ini menjawab pertanyaan umum tentang LlamaIndex dan praktik RAG. LlamaIndex dikenal karena indexing dokumen dan integrasi parser serta ADW. Sementara itu, LangChain lebih fokus pada orkestrasi chain dan pipeline kustom.

Haystack sangat cocok jika Anda butuh integrasi mendalam dengan Elasticsearch dan pipeline IR. Ini menjadikannya pilihan yang tepat untuk beberapa kebutuhan.

Ya, LlamaIndex bisa dijalankan lokal tanpa OpenAI. Anda bisa menggunakan model lokal seperti Ollama dengan llama3.1 dan embedding dari HuggingFace. Ini memungkinkan Anda untuk mengatur sistem di lokasi Anda sendiri.

Paket tambahan seperti llama-index-llms-ollama dan llama-index-embeddings-huggingface diperlukan untuk konfigurasi. Ini membantu Anda dalam mengatur sistem dengan lebih baik.

Untuk volume besar, gunakan vector store yang skalabel seperti Milvus. Jalankan ingestion asinkron dan persist index untuk memastikan data tetap terorganisir. Jika Anda tidak ingin mengelola infrastruktur, layanan terkelola seperti Zilliz Cloud bisa membantu.

Simpan jejak node (doc_id dan posisi) untuk memastikan jawaban dapat ditelusuri. Sertakan kutipan serta record nodes yang dipakai oleh query_engine. Ini membantu dalam memahami proses pencarian.

Pertimbangkan ADW ketika ada berbagai tipe dokumen, aturan bisnis kompleks, atau kebutuhan menulis kembali ke sistem. ADW menghubungkan parsing, retrieval, reasoning, dan action dengan kontrak data terketik. Pilih vector store berdasarkan skala, latensi, kemampuan async, dan biaya.

Milvus cocok untuk skala besar, sedangkan FAISS atau Chroma lebih cocok untuk local ringan. Pinecone atau Weaviate bagus untuk managed cloud. Untuk troubleshooting performa, ukur bottleneck antara embedding, vector store, dan LLM latency.

Gunakan async bila tersedia, dan terapkan reranking serta filter metadata untuk memperbaiki relevansi. Ini membantu meningkatkan kualitas hasil pencarian.